Thanks for background detail and test Nick. Very helpful. I'll give it some thought, hopefully tonight.
Tim. On Tue, Feb 16, 2010 at 04:12:00PM +0000, Nicholas Clark wrote: > On Tue, Feb 16, 2010 at 03:44:52PM +0000, [email protected] wrote: > > Revision: 1056 > > Author: [email protected] > > Date: Tue Feb 16 07:44:10 2010 > > Log: Better test for RT#54600 > > > > The problem is caused by S_call_body() in 5.8.8 and earlier making a direct > > call to Perl_pp_entersub(), rather than indirecting via > > PL_ppaddr[OP_ENTERSUB]. > > Hence any calls made through it (such as DESTROY) never reach our > > pp_subcall_profiler, and subr_entry_setup() is never called to initialse > > subr_entry_ix. Hence if if the DESTROY routine (or an AUTOLOAD called in > > lieu > > of it) executes goto \&subname; that does reach pp_subcall_profiler, which > > assumes that it must (already) be inside a subroutine. > > > > I don't (yet) know what the right fix (or work around) is. > > http://code.google.com/p/perl-devel-nytprof/source/detail?r=1056 > > Specifically, I can see this comment: > > /* goto &sub opcode acts like a return followed by a call all in one. > * When this op starts executing, the 'current' subr_entry that was > * pushed onto the savestack by pp_subcall_profiler will be > 'already_counted' > * so the profiling of that call will be handled naturally for us. > * So far so good. > * Before it gets destroyed we'll take a copy of the subr_entry. > * Then tell subr_entry_setup() to use our copy as a template so it'll > * seem like the sub we goto'd was called by the same sub that called > * the one that executed the goto. Except that we do use the fid:line > * of the goto statement. That way the call graph makes sense and the > * 'calling location' make sense. Got all that? > */ > > I assume that the work around is that if we arrive at a goto &sub > with subr_entry_ix 0, we skip the copy part, and treat it as an entersub > (possibly at the line of the goto, given that we can infer that it won't > be possible to merge the timing back to the location of the caller of > the original subroutine). > > But I'm not sure of the right way to do that. > > Nicholas Clark > > -- > 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] > -- 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]
