At least I have found a sure way to verify that a segfault is caused by the wrong context. When you get a core trace where a Perl_ call, passing interpreter argument (my_perl on Unix, interpreter on win32), is followed by another Perl_ call, which doesn't pass this argument, go that that frame with the latter call and issue
(gdb) p PL_curinterp
if it doesn't match the interepreter (or my_perl) argument from the call one frame higher, you know what the problem is. In your trace:
VMem::Free(void * 0x00acea1c) line 208 + 3 bytes CPerlHost::Free(void * 0x00acea1c) line 59 + 34 bytes PerlMemFree(IPerlMem * 0x00262434, void * 0x00acea1c) line 302 Perl_safesysfree(void * 0x00acea1c) line 143 + 26 bytes
(gdb) p PL_curinterp
Perl_sv_clear(interpreter * 0x012aff6c, sv * 0x013a1b3c) line 5198 + 13 bytes
(gdb) up (gdb) p interpreter
if the two are not the same, the problem is clear.
PL_curinterp is a true global variable, so it's impossible to maintain it per interpreter.
The next step is to figure out how to set the perl context every time we select a new interepreter without incurring too much overhead and encapsulate this function together with the selector code so not to clutter the code and prevent forgetting to set the context in the newly added code. I will keep you posted.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
