On Tue, Feb 16, 2016 at 10:05:32AM +0000, Tim Bunce wrote: > On Tue, Feb 16, 2016 at 09:52:46AM +0000, Tim Bunce wrote: > > On Mon, Feb 15, 2016 at 04:13:12PM +0000, Dave Mitchell wrote: > > > > > > More generally, there are several XS modules broken by my context work > > > (because they assume non-API stuff). I could probably fix most of them, > > > if people thought it was a good use of my time. > > > > I thought Devel::NYTProf was broken by the context changes but when I look > > I see more than 50% of reports are passing: > > http://matrix.cpantesters.org/?dist=Devel-NYTProf%206.02;perl=5.23.8;reports=1 > > So now I'm unsure what's happening. > > Ah, they're all failing after 2016-02-02 when, I presume, the patch > landed in blead. > > > If the code is affected (and I'd be both amazed and delighted if it wasn't) > > then I'd very much appreciate some clear pointers to what I'd need to change. I've had a quick play with it. Two issues I've seen so far: 1) CXt_LOOP_FOR has been split into CXt_LOOP_ARY and CXt_LOOP_LIST. This was a fairly trivial fix. The attached WIP diff fixes up that. 2) Because pushing a context such as CXt_SUB now saves almost everything in fields in the context stack rather than saving some state in the save stack, its possible to have two nested subs calls each with the same savestack index. This seems to screw up the subr_entry_ix / prev_subr_entry_ix stuff in NYTProf.xs, which seems to assume that different sub entries will have different subr_entry_ix's. I don't understand enough about how subr_entry_ix is used to know how to fix that. Here's a simple example of failure: N=$HOME/tmp/cpan/src/Devel-NYTProf-6.02 P=$HOME/perl5/git/bleed.out/bin/perl5.23.8 export PERL5LIB=$N/blib/arch:$N/blib/lib $P -d:NYTProf -e "sub f { } f()" which gives: NYTProf panic: stack is confused, giving up! (Try running with subs=0) ix=0 prev_ix=0 perl5.23.8: NYTProf.xs:2784: pp_subcall_profiler: Assertion `subr_entry' failed. -- Counsellor Troi states something other than the blindingly obvious. -- Things That Never Happen in "Star Trek" #16Thread Previous | Thread Next