Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the devel-nytprof CPAN distribution.

Report information
The Basics
Id: 86548
Status: resolved
Priority: 0/
Queue: devel-nytprof

People
Owner: Nobody in particular
Requestors: zefram [...] fysh.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: crash with multiple shutdown
Date: Fri, 28 Jun 2013 14:34:19 +0100
To: bug-Devel-NYTProf [...] rt.cpan.org
From: Zefram <zefram [...] fysh.org>
Devel::NYTProf can cause a crash if finish_profile() is called after the Perl interpreter has been destructed. This can occur if using the new libcexit option, if Perl exits in an orderly fashion. The crash occurs during hv_clear(), if the scope stack's memory allocation has gone away. The fix is to add "if(HvUSEDKEYS(sub_callers_hv))" in front of "hv_clear(sub_callers_hv);" in finish_profile(). -zefram
I'd wondered about this possibility. Seems like we're on very unsafe ground as anything owned by perl will have been freed. Hopefully nothing would have reused the memory between the interp being destroyed and the atexit callback so we can safely peruse the remnants. Is there a reliable way to tell that the interp has been destroyed?
Subject: Re: [rt.cpan.org #86548] crash with multiple shutdown
Date: Fri, 28 Jun 2013 16:31:37 +0100
To: Tim_Bunce via RT <bug-devel-nytprof [...] rt.cpan.org>
From: Zefram <zefram [...] fysh.org>
Tim_Bunce via RT wrote: Show quoted text
>like we're on very unsafe ground as anything owned by perl will have >been freed.
Not everything. The sub_callers_hv has a reference owned by Devel::NYTProf that is never cancelled. Perl destruction doesn't know about that reference. So sub_callers_hv will never be reduced to refcount zero and will never be freed. We're OK to examine it. Show quoted text
>Is there a reliable way to tell that the interp has been destroyed?
Not that I can see. I think we're OK because the hv_clear() is the only cleanup operation that requires a working interpreter, and if the interpreter destructed then we already performed cleanup at that point, so detecting that the hash is already clear suffices. -zefram
Fixed in 5.05. Thanks!