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! > PS: Any reason why called_subname_pv isnt't called called_subnam_pv > for consistency? 'subname' is the fully qualified name, including the package, and 'subnam' is the name without the package. Lame, but effective :) > I also find that I'm easily getting confused > between caller_subnam_sv and called_subnam_sv. It would be > nice to have more than a single character difference in these > names. Unfortunately I can't come up with good alternatives. Same here. Tim. --~--~---------~--~----~------------~-------~--~----~ 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] -~----------~----~----~----~------~----~------~--~---
