develooper Front page | perl.perl5.porters | Postings from May 2013

[perl #118139] Storable in DESTROY blocks

Thread Previous | Thread Next
Reini Urban via RT
May 23, 2013 16:26
[perl #118139] Storable in DESTROY blocks
Message ID:
On Thu May 23 09:08:29 2013, LeonT wrote:
> On Thu, May 23, 2013 at 5:30 PM,
> <> wrote:
> > Storable segfaults when being used in DESTROY blocks during global
> > destruction, when accessing an already freed PL_modglobal or the 
> > 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 
#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 
#4  0x000000000054120e in Perl_runops_debug (my_perl=0x816010) at 
#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 
#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

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About