On Sun May 26 11:14:03 2013, sprout wrote: > On Fri May 10 04:36:11 2013, nicholas wrote: > > $ ~/Sandpit/5000/bin/perl -e 'sub B {package A; reset}; delete > > $::{"A::"}; B()' > > Segmentation fault: 11 (core dumped) > > $ ~/Sandpit/5000/bin/perl -v > > > > This is perl, version 5.000 > ... > > > The bug isn't in reset - that's just the easiest way I found to write > > code > > which accesses CopSTASH() > > The other place that accesses CopSTASH is pp_caller, which checks to > make sure that it is an HV first to avoid such a crash. Maybe reset > needs to do the same thing. Not just reset. Another, because of the CopSTASH in pp.c:S_rv2gv: $ ./perl -Ilib -e 'sub B { package A; open my $a, "./perl" } delete $::{A::::}; B()' Segmentation fault: 11 It crashes when a GV is autovivified and the stash is being given a backref to it. This one from pp.c:pp_bless: $ ./perl -Ilib -e 'sub B { package A; bless []} delete $::{A::::}; B()' Assertion failed: (SvTYPE(stash) == SVt_PVHV), function S_curse, file sv.c, line 6442. Abort trap: 6 The assertion fails during destruction, when the stash the object points to turns out not to be an HV. pp_ctl.c:S_doeval: $ perl5.19.1 -e 'sub B { package A; eval "\$a"} delete $::{A::::}; B()' Assertion failed: (SvTYPE(hv) == SVt_PVHV), function Perl_hv_common, file hv.c, line 357. Abort trap: 6 PL_curstash ends up pointing to the eval cv, which happens to have reused the same sv. I think the only practical way to fix the crashes is for all these code paths to check for a freed stash. > > That would prevent crashing, but still not solve the underlying problem, > which is the subject of #113486. After fixing the above, I plan to resolve this ticket, as #113486 already covers the underlying problem, and merging the two might be confusing to future readers. -- Father Chrysostomos --- via perlbug: queue: perl5 status: open https://rt.perl.org:443/rt3/Ticket/Display.html?id=117941Thread Previous | Thread Next