Front page | perl.perl5.porters |
Postings from October 2003
On Thu, Oct 09, 2003 at 09:43:10PM +0100, Nicholas Clark wrote:
> On Tue, Oct 07, 2003 at 05:49:37PM -0000, berikv@xs4all.nl (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 http://www.ccl4.org/~nick/P/24154_valgrind )
>
> 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/Storable.so)
> ==432== by 0x41B5C589: pstore (in /home/richardc/archive/penfold-usr-local/perl5.8.1/lib/5.8.1/i686-linux/auto/Storable/Storable.so)
> ==432== by 0x41B60E30: XS_Storable_pstore (in /home/richardc/archive/penfold-usr-local/perl5.8.1/lib/5.8.1/i686-linux/auto/Storable/Storable.so)
> ==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.
Dave.
--
Standards (n). Battle insignia or tribal totems.
Thread Previous
|
Thread Next