A query on XS programing with multiple interpreter on Linux!!!

pijush has asked for the wisdom of the Perl Monks concerning the following question:

Hi Monks!

I am facing a typical problem in XS programming with multiple interpreter on Linux 2.1 advanced server. If any one please give me any pointers it will be very helpful to me. I have built perl with following options.
config_args='-des -Dcc=cc -Dcf_email=PerlDirect@ActiveState.com -Dusethreads -Duseithreads -Dcf_by=ActiveState -Uinstallusrbinperl -Ud_sigsetjmp -Dinc_version_list=5.6.0/i686-linux-thread-multi 5.6.0 -Dprefix=/home/pijush/project/Testing/Perl and gccversion is '2.95.2 20000220 (Debian GNU/Linux)', libc is 'libc-2.1.3.so'.
In xs(say test.xs) file I have written following code

.......
MODULE=TestModule::TestAPI       PACKAGE=TestModule:Test1

int TestMethod1(.......)
.......
.....

MODULE=TestModule::TestAPI       PACKAGE=TestModule:Test2

int TestMethod2(........)
........
.......
[download]

I have built a shared library from this xs file and place it in my perl location. After that I have written a test script (say test.pl) to test the code.

use TestModule::TestAPI;

my $testbase = TestModule::TestAPI->New();
my $var1 = $testbase->TestMethod1(...);
my $var2 = $testbase->TestMethod2(...);
[download]

But the test script is generatting an error on TestMethod2. To debug the error what I have done, I put an infinite loop on TestMethod2 and built so file without optimization and -g option. Then I started the script and to start debugging I have attached the main process (since I have built my perl with MULTIPLICITY USE_ITHREADS, so there is 4-5 process running simultaneously)with gdb. At my surprise I observerved that although the script stopped at infinite loop but after stepping (using step command) gdb showing code which is present in TestMethod1.
I have tried with perl -d test.pl without modifying test.xs(i.e. without placing infinite loop), but the programme hangs during the execution of TestMethod2.
Can any one please give me any pointers how can I check why this strange thing is happening on Linux?
Thanks in advance.
Regards
-Pijush

Comment on A query on XS programing with multiple interpreter on Linux!!! Select or Download Code

Replies are listed 'Best First'.
Re: A query on XS programing with multiple interpreter on Linux!!! by Anonymous Monk on Apr 19, 2004 at 10:46 UTC
I am facing a typical problem in XS programming with multiple interpreter on Linux 2.1 advanced server. It's a typical problem? What's the typical solution? In xs(say test.xs) file I have written following code `....... MODULE=TestModule::TestAPI PACKAGE=TestModule:Test1 int TestMethod1(.......) .......` That's not code. If you seriously want help, show some real code. Can any one please give me any pointers how can I check why this strange thing is happening on Linux? Without more information that is impossible.	[reply]
Re: Re: A query on XS programing with multiple interpreter on Linux!!! by pijush (Scribe) on Apr 19, 2004 at 12:44 UTC
I got the problem. Actually I was little confused after seeing the code in gdb. gdb shows the code which is present in my .c file but actually it is executing the real code corresponding to the appropriate method. I just look the corresponding line no shown by gdb in .xs file and find that it is executing the right code. I really don't know why gdb is not showing appropriate code from .c file!!!! Thanks Regards -Pijush	[reply]
Re: Re: Re: A query on XS programing with multiple interpreter on Linux!!! by hv (Prior) on Apr 19, 2004 at 15:59 UTC
In the process of converting the .xs file to .c, lots of `#line` directives are introduced to allow the debugger to know the original source of the lines of code directly copied from the XS. It is possible that gdb is getting confused by these, or xsubpp may have got confused and emitted the wrong lines - you could try stripping out all the lines in the .c file starting `#line` and recompiling, which might allow gdb to do a better job. First though it is worth confirming that your program is actually sitting in the infinite loop; you might consider printing a dot and then sleeping a second within the loop, or alternatively you could try to force an error for gdb to catch, for example by dereferencing a null pointer: `char c = (char)0;` [download] Hugo	[reply] [d/l] [select]