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

Hello brothers,

I'm trying to embed several perl interpreters in C. The interpreters can be used in an interleaved fashion, i.e. there are running several of them "at the same time". Here is the source code.

The program creates two perl interpreters and both of them try to load the module Module::Runtime. The problem is that it crashes or cycles infinitely when it tries to load the module into the second interpreter.

For the sake of completeness there are two routines that load the module (perl_load_module_1 and perl_load_module_2). Neither of them works.

I have compiled it with the command:

gcc -o $@ $^ `perl -MExtUtils::Embed -e ccopts -e ldopts`

I've also tried to load other modules instead of Module::Runtime and all of them worked flawlessly.

I use the most recent perl-5.12.3, Mod::Runtime version is 0.007. Running perl -V gives me: http://pastebin.com/GvvciPSJ

I have been fighting this for over a week to no avail. In the end I used Module::Load instead of Module::Runtime, but nevertheless I would like to know where is the real problem.

Thank you very much for any replies.

daneus

Replies are listed 'Best First'.
Re: Multiple perl interpreters and Module::Runtime (-d)
by tye (Sage) on Feb 04, 2011 at 18:37 UTC

    Use the Perl debugger to figure out exactly where the second-time loading is going wrong. Scanning p5git://perl.c. I see that the debugger is enabled by: 

        PL_perldb = PERLDB_ALL;
    init_debugger();

    [download]

    Since you want more than one interpreter instance per process, then you need MULTIPLICITY defined (as you do) which means that p5git://grep=PL_perldb gets defined as (vTHX->Iperldb) in p5git://embedvar.h. and init_debugger() actually becomes Perl_init_debugger(aTHX). I'll let you look up how to get vTHX and aTHX defined properly based on the allocated interpreter you have a pointer to.

    - tye        

[reply]
[d/l]
[select]
      Thanks for the hint. I've tried the Perl debugger and found the following:

      It is crashing in the module Exporter, line 64: 

      [31499->31499]  DB<1> Exporter::import(/export/packages/perl-5.12.3/li
+b/5.12.3/Exporter.pm:64):
64:       *{"$callpkg\::$_"} = \&{"$pkg\::$_"} foreach @_;

      [download]
      where the variables are: 
      $callpkg = "Module::Runtime"
@_ = ("is_string")
$_ = "is_string"
$pkg = "Params::Classify"

      [download]
      When I tried to feed the debugger with this: 
      &{"$pkg\::$_"}

      [download]
      the debugger crashed. So there is probably something bad going on in Params::Classify. The generated core dump shows, that it crashed in lib/params/Classify.xs:635. The backtrace is very high and starts like this: 
      ...
#87243 0x00007fd820981b7a in myck_entersub (my_perl=0x2143000, op=0x26
+0b250) at lib/Params/Classify.xs:635
#87244 0x00007fd820981b7a in myck_entersub (my_perl=0x2143000, op=0x26
+0b250) at lib/Params/Classify.xs:635
#87245 0x00007fd820981b7a in myck_entersub (my_perl=0x2143000, op=0x26
+0b250) at lib/Params/Classify.xs:635
#87246 0x00007fd820981b7a in myck_entersub (my_perl=0x2143000, op=0x26
+0b250) at lib/Params/Classify.xs:635
#87247 0x00007fd826cae142 in Perl_convert (my_perl=0x2143000, type=173
+, flags=192, o=0x260b250) at op.c:2652
#87248 0x00007fd826cb351c in Perl_utilize (my_perl=0x2143000, aver=1, 
+floor=147, version=0x0, idop=0x2617d20, 
    arg=0x264e210) at op.c:3979
#87249 0x00007fd826d4d17c in Perl_yyparse (my_perl=0x2143000) at perly
+.y:674
#87250 0x00007fd826ef2d6d in S_doeval (my_perl=0x2143000, gimme=2, sta
+rtop=0x0, outside=0x0, seq=2054)
    at pp_ctl.c:3112
#87251 0x00007fd826efa35e in Perl_pp_require (my_perl=0x2143000) at pp
+_ctl.c:3690
#87252 0x00007fd826da5fc8 in Perl_runops_debug (my_perl=0x2143000) at 
+dump.c:2049
#87253 0x00007fd826cdadb6 in Perl_eval_sv (my_perl=0x2143000, sv=0x216
+0e28, flags=4) at perl.c:2705
#87254 0x0000000000401a47 in perl_load_module_1 ()
#87255 0x00000000004040f9 in main ()

      [download]
      The function "myck_entersub" is calling itself ad infinitum, which is not good. My guess is there's something wrong with Classify.xs. Unfortunately, I don't know how to fix it. Do you have any ideas?
[reply]
[d/l]
[select]
            *{"$callpkg\::$_"} = \&{"$pkg\::$_"} foreach @_;

        [download]
        ... When I tried to feed the debugger with this: 
        &{"$pkg\::$_"}

        [download]

        \&... would never do what &... does. \&... takes a reference to a subroutine while &... invokes a subroutine. So what &{"$pkg\::$_"} does is rather irrelevant. It is indeed unfortunate that Params::Classify::is_string() stupidly produces an endless recursive loop when not given any parameters. But that likely has nothing to do with your original problem.

        The author of that module even included: 

        sub is_string($);

        [download]

        Which makes it fatal to call is_string() with no arguments... unless you use the prefix & to disable sub prototype checking, as you did. So even a bug report against the module might not yield anything.

        It is crashing in the module Exporter, line 64:

        How does it crash?

        - tye        

[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom