Alan McKay <alan.mc...@gmail.com> writes: > Here is what I am doing based on the mod-perl debugging page I > referred to in my first email. I basically load the core dump in > gdb, and then alternately do "up" and "curinfo" on each line shown. > Sometimes I end up with what I got here where I get to a certain point > and it says "cannot access memory at ...", and sometimes I can get > through the whole back trace in the "up/curinfo" manner without that. > But never does it tell me it found a my_perl > > Not sure why sometimes I get that error and sometimes not. To the > best of my knowledge I'm doing the same thing every time. > >> end > (gdb) bt > #0 0x0044e172 in Perl_cv_const_sv () from > /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so > #1 0x00442a7c in Perl_yylex () from
It looks like maybe it's dying in the parser... > /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so > #2 0x0044b295 in Perl_yyparse () from > /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so > #3 0x004b8200 in Perl_pp_range () from > /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so > #4 0x004ba0b2 in Perl_pp_require () from ...while parsing an external file. Maybe sticking some debugging information around your require/use/do statements (inside of BEGIN blocks) would help you narrow down what file it is. I have had to debug these things before, and they're very painful! I usually end up commenting out half the code at a time to narrow things down, and it's never what I expect. Usually it's a module with a compiled library, i.e. not a pure-Perl module. Good luck! ----Scott.
