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 CPerlHost::Free() PL_curinterp: 0x002643cc my_perl: Error: symbol "my_perl" not found PerlMemFree() PL_curinterp: 0x002643cc my_perl: Error: symbol "my_perl" not found Perl_safesysfree() PL_curinterp: 0x002643cc my_perl: 0x002643cc Perl_sv_clear() PL_curinterp: 0x002643cc my_perl: 0x002643cc Perl_sv_free() PL_curinterp: 0x002643cc my_perl: 0x002643cc Perl_free_tmps() PL_curinterp: 0x002643cc my_perl: 0x002643cc perl_destruct() PL_curinterp: 0x002643cc my_perl: 0x002643cc modperl_perl_destruct() PL_curinterp: Error: symbol "PL_curinterp" not found my_perl: 0x002643cc
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).
- Steve
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
