Jan, any luck with this? Tim.
On Tue, Jul 28, 2009 at 06:58:51PM -0700, Tim Bunce wrote: > > On Tue, Jul 28, 2009 at 03:26:29PM -0700, Jan Dubois wrote: > > > > On Tue, 28 Jul 2009, Jan Dubois wrote: > > > On Mon, 27 Jul 2009, Elliot Shank wrote: > > > > Using Strawberry Perl 5.10.0.4, t/50-errno.t crashes perl during test > > > > 8. I tracked it down to r834, it works in r833 and crashes up through > > > > the current r847. > > > > > > I can reproduce the problem too (with MSC instead of GCC). It seems to > > > happen > > > in the SvOK() test in this part of the code: > > > > > > /* Should we calculate the caller or can we reuse the > > > caller_subr_entry? > > > * Sometimes we'll have a caller_subr_entry but it won't have the > > > name yet. > > > * For example if the caller is an xsub that's callback into perl. > > > */ > > > if (profile_findcaller /* user wants us to calculate each > > > time */ > > > || !caller_subr_entry /* we don't have a caller > > > struct */ > > > || !caller_subr_entry->called_subpkg_pv /* we don't have caller > > > details */ > > > || !SvOK(caller_subr_entry->called_subnam_sv) > > > > > > The stack trace is: > > > > > > subr_entry_setup(interpreter * 0x015d3fc4, cop * 0x01b806d8, > > > subr_entry_st * 0x00000000) line 2433 + 26 bytes > > > pp_subcall_profiler(interpreter * 0x015d3fc4, int 0x00000000) line 2556 > > > + 15 bytes > > > pp_entersub_profiler(interpreter * 0x015d3fc4) line 2488 + 13 bytes > > > > > > caller_subr_entry->called_subnam_sv doesn't look like a valid SV*, but > > > I can access all the fields from the debugger, so I'm not sure why > > > this is generating an access violation. Or maybe I'm reading the > > > disassembled code incorrectly; I didn't disable -O2 yet. I can have > > > another look tomorrow, but I thought maybe the exact location gives > > > you enough hints to understand what might be going wrong. > > > > Ok, I was confused. caller_subr_entry->called_subnam_sv is actually > > NULL, explaining the access violation. I was looking at > > caller_subr_entry->caller_subnam_sv, which seemed to contain invalid > > data, but at least pointed to readable memory. > > > > I added a checl to the condition above for > > > > || !caller_subr_entry->called_subnam_sv > > > > before testing for SvOK(), but then the crash happened again and > > caller_subr_entry->called_subnam_sv turned out to be 1. > > > > I don't quite understand how this can happen; any ideas what I should be > > looking at? > > Nope. There's no way that I can see for called_subnam_sv to be 1. > I figure it's a compiler bug or a memory corruption. > Try with -O disabled. > > I've seen that test die sometimes, but only when running "make prove" > which does a prove -j 9 and I can't reproduce it now. > > Using perl -Mblib t/50-errno.t > try with some options disabled (largest subset of leave=0:blocks=0:stmts=0) > then try cutting down the test file as small as possible, > and then send me a trace file. Say level 9. > > Thanks! --~--~---------~--~----~------------~-------~--~----~ You've received this message because you are subscribed to the Devel::NYTProf Development User group. Group hosted at: http://groups.google.com/group/develnytprof-dev Project hosted at: http://perl-devel-nytprof.googlecode.com CPAN distribution: http://search.cpan.org/dist/Devel-NYTProf To post, email: [email protected] To unsubscribe, email: [email protected] -~----------~----~----~----~------~----~------~--~---
