Stas Bekman wrote:[...]
Steve Hay wrote:
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.
I can't do _exactly_ what you've written above (I'm using MSVC++ rather than gdb), but I can watch the value of any visible variables within each frame. If I'm doing this correctly then I don't actually see the problem that you describe. The value of "interpreter" isn't shown by MSVC++ in the "watch" window (it just gives me "{...}"!) but I guess you can see it from the stacktrace itself. Here's the stacktrace for for what I'm looking at now:
VMem::Free(void * 0x009fb864) line 208 + 3 bytes
CPerlHost::Free(void * 0x009fb864) line 59 + 34 bytes
PerlMemFree(IPerlMem * 0x00262434, void * 0x009fb864) line 302
Perl_safesysfree(void * 0x009fb864) line 143 + 26 bytes
Perl_sv_clear(interpreter * 0x002643cc, sv * 0x002653c4) line 5198 + 13 bytes
Perl_sv_free(interpreter * 0x002643cc, sv * 0x002653c4) line 5342 + 13 bytes
Perl_free_tmps(interpreter * 0x002643cc) line 189 + 13 bytes
perl_destruct(interpreter * 0x002643cc) line 456 + 23 bytes
modperl_perl_destruct(interpreter * 0x002643cc) line 146 + 9 bytes
modperl_interp_destroy(modperl_interp_t * 0x00924db0) line 128 + 12 bytes
modperl_interp_pool_destroy(void * 0x00851398) line 184 + 12 bytes
run_cleanups(cleanup_t * * 0x00852608) line 1979 + 13 bytes
apr_pool_destroy(apr_pool_t * 0x008525f8) line 755 + 12 bytes
apr_pool_clear(apr_pool_t * 0x0028a9e8) line 715 + 12 bytes
main(int 7, const char * const * 0x00282908) line 619
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e814c7()
So "interpreter" is 0x002643cc in the calls to modperl_perl_destruct() through to Perl_sv_clear(). Here's what the "watch" window shows me for the values of PL_curinterp and my_perl in each of those frames and the later frames as well:
VMem::Free() PL_curinterp: 0x002643cc my_perl: 0x002643cc
only the last one matters.
In particular, the PL_curinterp value within the Perl_safesysfree() frame (which didn't get the interpreter passed) is the same as the my_perl value within the Perl_sv_clear() frame (which did get the interpreter passed).
That's a bad news. In which case I don't know what the problem is on your side. Though we did see that messing with setting of the context helps things, so we might be still around the right track.
Since I can reproduce segfaults and I do get different values for PL_curinterp and the passed my_perl, I'll first tackle that one. And then we will get back to try to figure out what's wrong is on win32.
__________________________________________________________________ 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]
