develooper Front page | perl.perl5.porters | Postings from October 2003

Re: [perl #24154] Core dump when using Storable

Thread Previous | Thread Next
Dave Mitchell
October 17, 2003 16:20
Re: [perl #24154] Core dump when using Storable
Message ID:
On Thu, Oct 09, 2003 at 09:43:10PM +0100, Nicholas Clark wrote:
> On Tue, Oct 07, 2003 at 05:49:37PM -0000, (via RT) wrote:
> > When running this:
> > 
> >   perl -we '$db = bless {}; $db->{db}{12345}; use Storable; sub DESTROY { store(shift->{db},"outfile") }'
> > 
> > perl gets a SEGV signal and dumps core..
> > Hope i've supplied enough information.
> Yes. Thanks for this bug report. I can replicate this on 5.8.1 built on
> Debian. I have no idea quite what's going wrong. Running under valgrind I
> see this error on STDERR:
> Useless use of hash element in void context at -e line 1.
> and 55K of output (see )
> which seems to start with several repeats of this:
> ==432== Invalid read of size 4
> ==432==    at 0x41B5C436: do_store (in /home/richardc/archive/penfold-usr-local/perl5.8.1/lib/5.8.1/i686-linux/auto/Storable/
> ==432==    by 0x41B5C589: pstore (in /home/richardc/archive/penfold-usr-local/perl5.8.1/lib/5.8.1/i686-linux/auto/Storable/
> ==432==    by 0x41B60E30: XS_Storable_pstore (in /home/richardc/archive/penfold-usr-local/perl5.8.1/lib/5.8.1/i686-linux/auto/Storable/
> ==432==    by 0x80BE991: Perl_pp_entersub (in /home/richardc/archive/penfold-usr-local/perl5.8.1/bin/perl)
> ==432==    Address 0x4140471C is 68 bytes inside a block of size 148 free'd
> ==432==    at 0x40028C15: free (vg_replace_malloc.c:220)
> ==432==    by 0x80C64B1: Perl_sv_clear (in /home/richardc/archive/penfold-usr-local/perl5.8.1/bin/perl)
> ==432==    by 0x80C6825: Perl_sv_free (in /home/richardc/archive/penfold-usr-local/perl5.8.1/bin/perl)
> ==432==    by 0x80CC8F7: Perl_sv_clean_objs (in /home/richardc/archive/penfold-usr-local/perl5.8.1/bin/perl)

The short answer: doing anything from a DESTROY method during global
cleanup is always risky, as you don't know what else has already been
cleaned up.

The long answer: Storable has private "context" data structures which
it allocates as needed by creating an object SV and typecasting the
object's PVX (of the right size) to store this structure.
During global cleanup, these object(s) are freed, so you end up with
contexts accessible in freed memory. I don't know enough about Storable,
and what it uses its contexts for,and why it sees fit to allocate them
from PVs, in order to feel confident in trying to fix this.


Standards (n). Battle insignia or tribal totems.

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