diff options
| author | Father Chrysostomos <sprout@cpan.org> | 2010-10-03 10:46:52 -0700 |
|---|---|---|
| committer | Father Chrysostomos <sprout@cpan.org> | 2010-10-03 11:02:24 -0700 |
| commit | 95f567513aaa04ffb8bb9d148aff1a85b1eff161 (patch) | |
| tree | 4510923e11f5053e3000ae65b6fd2a166f4ff30e | |
| parent | e2bd2e2b51a3690b0515d3ac5d5d7e350cb446be (diff) | |
| download | perl-95f567513aaa04ffb8bb9d148aff1a85b1eff161.tar.gz | |
Avoid downgrading GVs during global destruction
Recently we’ve been getting assertions from gv.t like this:
Assertion failed: (SvTYPE(sv) != SVTYPEMASK), function Perl_sv_clear, file sv.c, line 5783.
This only happens in non-threaded builds and with PERL_DESTRUCT_LEVEL
set to 2 (as in make test).
These started with 13be902 (lvalue-to-glob assignment), but only
because of the tests it added.
The real cause turns out to be f746176, which introduced
gv_try_downgrade.
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.
Since memory-saving operations such as this downgrading are questiona-
ble anyway durng global destruction, skip it, at least for now.
| -rw-r--r-- | gv.c | 5 |
1 files changed, 5 insertions, 0 deletions
@@ -2593,6 +2593,11 @@ Perl_gv_try_downgrade(pTHX_ GV *gv) HEK *namehek; SV **gvp; PERL_ARGS_ASSERT_GV_TRY_DOWNGRADE; + + /* XXX Why and where does this leave dangling pointers during global + destruction? */ + if (PL_dirty) return; + if (!(SvREFCNT(gv) == 1 && SvTYPE(gv) == SVt_PVGV && !SvFAKE(gv) && !SvOBJECT(gv) && !SvREADONLY(gv) && isGV_with_GP(gv) && GvGP(gv) && |