Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Storable CPAN distribution.

Report information
The Basics
Id: 36087
Status: open
Priority: 0/
Queue: Storable

People
Owner: Nobody in particular
Requestors: dom [...] cpan.org
martin.ferrari [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in:
  • 2.13
  • 2.15
  • 2.18
Fixed in: (no value)



Subject: segfaults when called during global destruction
MIME-Version: 1.0
X-Mailer: MIME-tools 5.418 (Entity 5.418)
Charset: utf8
X-RT-Original-Encoding: utf-8
Content-Type: multipart/mixed; boundary="----------=_1211425175-8665-26"
Content-Length: 0
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
Content-Length: 820
Download (untitled) / with headers
text/plain 820b
This is apparently an old problem that went under the radar. It was already reported in May, 2005 in http://www.mail-archive.com/perl5-porters@perl.org/msg86928.html, but nobody could reproduce it at the time. Also it was discussed on http://www.perlmonks.org/?node_id=651966. I have tried the attached test in at least 4 different architectures (i386, ia64, armel and sparc64) in Debian, and also tried FreeBSD, RedHat, Mandriva and Gentoo. In every try, I got a segfault like this: $ perl test.pl Destroying Foo=HASH(0x6000000000009630), bar=baz at test.pl line 17 during global destruction. Segmentation fault $ uname -a Linux merulo 2.6.18-dsa-mckinley #1 SMP Mon Feb 11 09:57:09 MST 2008 ia64 GNU/Linux This seems to be the cause of -at least- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=315669 Thanks.
Subject: test.pl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------=_1211425175-8665-25"
X-Mailer: MIME-tools 5.418 (Entity 5.418)
Charset: utf8
Content-Length: 0
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: iso-8859-1
Content-Length: 0
Content-Type: text/x-perl; name="test.pl"
Content-Disposition: inline; filename="test.pl"
Content-Transfer-Encoding: binary
Content-Length: 264
Download test.pl
text/x-perl 264b
#!/usr/bin/perl use strict; use warnings; our $a = new Foo(); $a->{bar} = "baz"; package Foo; use Storable; sub new { return bless({}, "Foo"); } sub DESTROY { my $this = shift; warn "Destroying $this, bar=$this->{bar}"; my $f = Storable::freeze($this); }
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-2367-1279646098-1912.36087-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
RT-Send-CC: perl5-porters [...] perl.org
Content-Length: 1742
Download (untitled) / with headers
text/plain 1.7k
The testcase, for reference: #!/usr/bin/perl use strict; use warnings; our $a = new Foo(); $a->{bar} = "baz"; package Foo; use Storable; sub new { return bless({}, "Foo"); } sub DESTROY { my $this = shift; warn "Destroying $this, bar=$this->{bar}"; my $f = Storable::freeze($this); } Here's a workaround that Git instated due to this issue: http://github.com/git/git/commit/8ac3a667 I investigated it a bit, it's segfaulting at the very start of do_store(): here ==> dSTCXT; int status; When I manually expand that macro it ends up being: { SV *perinterp_sv = *hv_fetch(PL_modglobal, MY_VERSION, sizeof(MY_VERSION)-1, TRUE); stcxt_t * cxt; if (perinterp_sv && SvIOK(perinterp_sv) && SvIVX(perinterp_sv)) { IV x = SvIVX(perinterp_sv); void* ptr = INT2PTR(SV*,x); SV* rv = SvRV(ptr); => cxt = (stcxt_t *)SvPVX(rv); } else { cxt = (stcxt_t *) 0; } int status; ptr is an OK scalar, but its RV slot is NULL. Even if that call hadn't failed and cxt was set to 0 it would still segfault later in the function, e.g. here: if (cxt->s_dirty) clean_context(aTHX_ cxt); The problem is seemingly that Storable is looking at its own context during global destruction, but when it gets around to it perl has already started freeing the variables that it depends on. Looking at anything during global destruction is dangerous. Storable should either be fixed to hook into destruction earlier, or this limitation documented. Maybe there's also a workaround I haven't spotted.
From twists [...] gmail.com Wed Jul 21 09: 56:03 2010
CC: perl5-porters [...] perl.org
MIME-Version: 1.0
X-Spam-Status: No, score=-8.999 tagged_above=-99.9 required=10 tests=[AWL=0.914, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SPF_NEUTRAL=0.686] autolearn=ham
In-Reply-To: <rt-3.8.HEAD-2367-1279646098-1619.36087-7-0 [...] rt.cpan.org>
X-Spam-Flag: NO
References: <RT-Ticket-36087 [...] rt.cpan.org> <rt-3.8.HEAD-2367-1279646098-1619.36087-7-0 [...] rt.cpan.org>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
Message-ID: <AANLkTin44b9SmhSvljfPTlsecH434fpx4Jml0lRTQizZ [...] mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
X-Spam-Score: -8.999
Authentication-Results: hipster.bestpractical.com (amavisd-new); dkim=pass header.i= [...] gmail.com
Authentication-Results: hipster.bestpractical.com (amavisd-new); domainkeys=pass header.from=twists [...] gmail.com
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 2BD2B2409D5 for <cpan-bug+Storable [...] hipster.bestpractical.com>; Wed, 21 Jul 2010 09:56:03 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+Ym-MvbA5N8 for <cpan-bug+Storable [...] hipster.bestpractical.com>; Wed, 21 Jul 2010 09:56:01 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id C0E4124099C for <bug-Storable [...] rt.cpan.org>; Wed, 21 Jul 2010 09:56:00 -0400 (EDT)
Received: (qmail 20878 invoked by uid 103); 21 Jul 2010 13:57:48 -0000
Received: from x16.dev (10.0.100.26) by x1.dev with QMQP; 21 Jul 2010 13:57:48 -0000
Received: from mail-fx0-f50.google.com (HELO mail-fx0-f50.google.com) (209.85.161.50) by 16.mx.develooper.com (qpsmtpd/0.80) with ESMTP; Wed, 21 Jul 2010 06:57:45 -0700
Received: by fxm9 with SMTP id 9so3454929fxm.9 for <bug-Storable [...] rt.cpan.org>; Wed, 21 Jul 2010 06:57:42 -0700 (PDT)
Received: by 10.103.218.10 with SMTP id v10mr28876muq.125.1279720662130; Wed, 21 Jul 2010 06:57:42 -0700 (PDT)
Received: by 10.220.189.193 with HTTP; Wed, 21 Jul 2010 06:57:41 -0700 (PDT)
Delivered-To: cpan-bug+Storable [...] hipster.bestpractical.com
Subject: Re: [rt.cpan.org #36087] segfaults when called during global destruction
Domainkey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dNLjrsHSCmJWwj8mGIQ2PFtzEfTWAJ9tE14nH6Bj1vDyGzs9pc5ahRCTuAEp+puL/M 6PENE+W/qFqpW5sjK3Vh2UMd40amt7S+f0RtDCjJxNBVeICVIvcAzRDX1+CVRudvR6p9 2oNuKZ+vl1ayeQfdKnu2fQqoqnt+BOo+rknvM=
Return-Path: <twists [...] gmail.com>
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vJY5ck9X7DfWqWfYheQ9998EICcjrBBpUIH+ZcLmB+w=; b=iYSe2VrSavDOWBjxWA8HGl22+E2tmU13O8gAM5qopEXuduUlBLR7DkI5li73WE6c24 y7w7j5ZPsH7JqiRHlkinZPc+WPAybGzBgHI6sLP1eRryRtF6Sj3U5eUNlFW9LDRdQw8g HU/GZH7PwooFsrirBdpAez0W1YzEhqZwIrDsk=
X-Spam-Check-BY: 16.mx.develooper.com
X-Original-To: cpan-bug+Storable [...] hipster.bestpractical.com
X-RT-Mail-Extension: storable
Date: Wed, 21 Jul 2010 06:57:41 -0700
X-Spam-Level:
To: bug-Storable [...] rt.cpan.org
Content-Transfer-Encoding: quoted-printable
From: Joshua ben Jore <twists [...] gmail.com>
RT-Message-ID: <rt-3.8.HEAD-2367-1279720672-1088.36087-0-0 [...] rt.cpan.org>
Content-Length: 2495
Download (untitled) / with headers
text/plain 2.4k
On Tue, Jul 20, 2010 at 10:14 AM, AEvar Arnfjord Bjarmason via RT <bug-Storable@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=36087 > > > The testcase, for reference: > >    #!/usr/bin/perl > >    use strict; >    use warnings; > >    our $a = new Foo(); >    $a->{bar} = "baz"; > >    package Foo; >    use Storable; > >    sub new { >    return bless({}, "Foo"); >    } >    sub DESTROY { >    my $this = shift; >    warn "Destroying $this, bar=$this->{bar}"; >    my $f = Storable::freeze($this); >    } > > Here's a workaround that Git instated due to this issue: > http://github.com/git/git/commit/8ac3a667 > > I investigated it a bit, it's segfaulting at the very start of > do_store(): > >    here  ==> dSTCXT; >                  int status; > > When I manually expand that macro it ends up being: > >    { >        SV *perinterp_sv = *hv_fetch(PL_modglobal, >                                     MY_VERSION, sizeof(MY_VERSION)-1, > TRUE); >        stcxt_t * cxt; >        if (perinterp_sv && SvIOK(perinterp_sv) && SvIVX(perinterp_sv)) > { >            IV x = SvIVX(perinterp_sv); >            void* ptr = INT2PTR(SV*,x); >            SV* rv = SvRV(ptr); >    =>      cxt = (stcxt_t *)SvPVX(rv); >        } else { >            cxt = (stcxt_t *) 0; >        } >        int status; > > ptr is an OK scalar, but its RV slot is NULL. Even if that call hadn't > failed and cxt was set to 0 it would still segfault later in the > function, e.g. here: > >    if (cxt->s_dirty) >        clean_context(aTHX_ cxt); > > The problem is seemingly that Storable is looking at its own context > during global destruction, but when it gets around to it perl has > already started freeing the variables that it depends on. > > Looking at anything during global destruction is dangerous. Storable > should either be fixed to hook into destruction earlier, or this > limitation documented. Maybe there's also a workaround I haven't > spotted.
The problem as you described on IRC is that your Foo object is destroyed after Storable's object. There's relatively little that can be done with that under the current implementation which is that ->DESTROY calls have no promised order between objects. We could possibly however alter Storable's usage of its global object in $Storable::Cxt so it can be re-created when needed even during global destruction. Josh
MIME-Version: 1.0
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-2023-1462057350-5.36087-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 147
Download (untitled) / with headers
text/plain 147b
This appears (as far as running test.pl is concerned) to have been fixed somewhere between perl 5.14.3 and perl 5.20.1 (ie Storable 2.27 and 2.49).


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.