gv_try_downgrade leaves dangling pointers during global destruction #10689
If a subroutine contains an op that references a downgradable GV, then gv_try_downgrade, if called on that GV during global destruction, *might* leave dangling pointers elsewhere; where exactly I wot not.
This only happens in non-threaded builds and with PERL_DESTRUCT_LEVEL set to 2 (as in make test).
This was causing t/op/gv.t to give this assertion:
Assertion failed: (SvTYPE(sv) != SVTYPEMASK), function Perl_sv_clear, file sv.c, line 5783.
This started with commit 13be902 (lvalue-to-glob assigment), but only because of the tests it added.
It was actually caused by f746176, which added gv_try_downgrade.
I’ve made gv_try_downgrade simply return during global destruction with commit 95f5675.
This ticket is a reminder that those dangling pointers need to be dealt with some day. (I still think gv_try_downgrade should be skipped during global destruction, regardless.)
To reproduce, delete the following line from gv.c:Perl_gv_try_downgrade:
if (PL_dirty) return;
Then compile perl with -DDEBUGGING (but without threads) and run:
cd t; PERL_DESTRUCT_LEVEL=2 ./perl harness -v op/gv.t
This perlbug was built using Perl 5.10.1 - Thu Sep 24 18:07:44 PDT 2009
Site configuration information for perl 5.13.5:
Configured by sprout at Fri Oct 1 09:23:16 PDT 2010.
Summary of my perl5 (revision 5 version 13 subversion 5) configuration:
Locally applied patches:
@INC for perl 5.13.5:
Environment for perl 5.13.5:
On Sun, 03 Oct 2010 19:54:09 GMT, sprout wrote:
While 'PL_dirty' still exists in C code underneath cpan/, dist/ and ext/, it no longer exists in gv.c or other core C files. Consequently, I can no longer reproduce the problem in the manner advised more than 6 years ago.
Is the ticket closable?
Thank you very much.
James E Keenan via RT <firstname.lastname@example.org> wrote:
It still has a stub definition in perl.h that's only made available to
# define PL_amagic_generation PL_na
The Perl_gv_try_downgrade() function still has the equivalent logic to
/* XXX Why and where does this leave dangling pointers during global
However, commenting that out doesn't allow me to reproduce the
On Sat, Jan 07, 2017 at 05:59:55PM +0000, Aaron Crane wrote:
I can reproduce it on the old commit sprout mentioned as when the problem
In the absence of any contrary information, I'm marking this ticket