Front page | perl.perl5.porters |
Postings from May 2013
[perl #118139] Storable in DESTROY blocks
Thread Previous
|
Thread Next
From:
Reini Urban via RT
Date:
May 23, 2013 16:26
Subject:
[perl #118139] Storable in DESTROY blocks
Message ID:
rt-3.6.HEAD-2650-1369326390-1271.118139-15-0@perl.org
On Thu May 23 09:08:29 2013, LeonT wrote:
> On Thu, May 23, 2013 at 5:30 PM, rurban@cpanel.net
> <perlbug-followup@perl.org> wrote:
> > Storable segfaults when being used in DESTROY blocks during global
> > destruction, when accessing an already freed PL_modglobal or the
internal
> > ctx.
> > The best fix is to die if used in global destruction.
> > See the new test t/destroy.t, which crashes in all perl versions.
> >
> > Since this Storable fix needs to be released on CPAN also, I had to
> > add some compatibility fixes, tested back to 5.6.
>
> This doesn't make sense to me. perl deliberately destroys all objects
> before destroying anything else. PL_modglobal should still exist when
> any DESTROY is run.
gdb --args /usr/local/bin/perl5.18.0d -Mblib t/destroy.t
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7e395d0 in do_retrieve (my_perl=0x816010, f=0x831b68, in=0x0,
optype=0) at Storable.xs:5997
5997 dSTCXT;
(gdb) bt
#0 0x00007ffff7e395d0 in do_retrieve (my_perl=0x816010, f=0x831b68,
in=0x0, optype=0) at Storable.xs:5997
#1 0x00007ffff7e3a8e0 in pretrieve (my_perl=0x816010, f=0x831b68) at
Storable.xs:6227
#2 0x00007ffff7e3ba4b in XS_Storable_pretrieve (my_perl=0x816010,
cv=0xa83ae8) at Storable.xs:6436
#3 0x00000000005aa708 in Perl_pp_entersub (my_perl=0x816010) at
pp_hot.c:2875
#4 0x000000000054120e in Perl_runops_debug (my_perl=0x816010) at
dump.c:2213
#5 0x000000000045e067 in Perl_call_sv (my_perl=0x816010, sv=0x944410,
flags=45) at perl.c:2766
#6 0x00000000005e1eae in S_curse (my_perl=0x816010, sv=0x819268,
check_refcnt=true) at sv.c:6482
#7 0x00000000005df139 in Perl_sv_clear (my_perl=0x816010,
orig_sv=0x819268) at sv.c:6117
#8 0x00000000005e2595 in Perl_sv_free2 (my_perl=0x816010, sv=0x819268,
rc=1) at sv.c:6583
#9 0x00000000005ad71f in S_SvREFCNT_dec_NN (my_perl=0x816010,
sv=0x819268) at inline.h:84
#10 0x00000000005ae1f7 in do_clean_objs (my_perl=0x816010, ref=0x9f8158)
at sv.c:480
#11 0x00000000005addc3 in S_visit (my_perl=0x816010, f=0x5ade78
<do_clean_objs>, flags=2048, mask=2048) at sv.c:422
#12 0x00000000005af48a in Perl_sv_clean_objs (my_perl=0x816010) at
sv.c:577
#13 0x0000000000456d70 in perl_destruct (my_perl=0x816010) at perl.c:766
#14 0x000000000041dcee in main (argc=3, argv=0x7fffffffe698,
env=0x7fffffffe6b8) at perlmain.c:125
$ make Storable.i
$ grep dSTCXT Storable.i
#define dSTCXT_SV SV *perinterp_sv = *hv_fetch(PL_modglobal, MY_VERSION,
sizeof(MY_VERSION)-1, TRUE)
#define dSTCXT_PTR(T,name) T name = ((perinterp_sv &&
SvIOK(perinterp_sv) && SvIVX(perinterp_sv) ?
(T)SvPVX(SvRV(INT2PTR(SV*,SvIVX(perinterp_sv)))) : (T) 0))
#define dSTCXT dSTCXT_SV; dSTCXT_PTR(stcxt_t *, cxt)
But my testcase is too optimized to reproduce the bug.
It fails with the last line changed to:
- foo->new();
+ $x = foo->new();
--
Reini Urban
---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=118139
Thread Previous
|
Thread Next