Core dump in Storable::store #8468

p5pRT · 2006-05-30T16:21:07Z

Migrated from rt.perl.org#39246 (status was 'open')

Searchable as RT39246$

p5pRT · 2003-03-03T15:02:53Z

From @nwc10

Created by @nwc10

$ perl5.8.0 memobang.pl
Segmentation fault

$ cat memobang.pl
#!/usr/local/bin/perl -w
use strict;

my $cachename = "$0.cache";
use Memoize;
use Memoize::Storable;

# $Memoize::Storable::Verbose = 1;

tie my %cache => 'Memoize::Storable', $cachename;
memoize 'factorise', LIST_CACHE => [HASH => \%cache];

sub factorise {
}

I can't get it shorter than that. Turning on Verbose isn't very interesting
(in this case with blead, and no copy on write (oops)):

$ ./perl -Ilib memobang.pl
Memoize::Storable::TIEHASH(memobang.pl.cache, )
Memoize::Storable::DESTROY()
Segmentation fault (core dumped)

Once a valid emptry Storable file exists I don't see a problem. Likewise not
actually memozing a function removes the SEGV. I'm confused.

Nicholas Clark

Perl Info


Flags:
    category=core
    severity=medium

Site configuration information for perl v5.8.0:

Configured by nick at Fri Jul 19 22:00:42 BST 2002.

Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.4.18-rmk7, archname=armv4l-linux
    uname='linux bagpuss.unfortu.net 2.4.18-rmk7 #10 sun jun 23 21:43:05 bst 2002 armv4l unknown '
    config_args='-Dcc=ccache gcc-3.0 -Dld=gcc-3.0 -Ubincompat5005 -Uinstallusrbinperl -Dcf_email=nick@ccl4.org -Dperladmin=nick@ccl4.org -Dinc_version_list=  -Dinc_version_list_init=0 -Doptimize=-Os -de -Uusethreads'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='ccache gcc-3.0', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-Os',
    cppflags='-fno-strict-aliasing -I/usr/local/include'
    ccversion='', gccversion='3.0.4', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='gcc-3.0', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lgdbm -ldbm -ldb -ldl -lm -lc -lcrypt -lutil
    perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil
    libc=/lib/libc-2.2.4.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.2.4'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.0:
    /usr/local/lib/perl5/5.8.0/armv4l-linux
    /usr/local/lib/perl5/5.8.0
    /usr/local/lib/perl5/site_perl/5.8.0/armv4l-linux
    /usr/local/lib/perl5/site_perl/5.8.0
    /usr/local/lib/perl5/site_perl
    .


Environment for perl v5.8.0:
    HOME=/home/nick
    LANG (unset)
    LANGUAGE (unset)
    LC_CTYPE=en_GB.ISO-8859-1
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/nick/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/sbin:/usr/sbin:/usr/local/sbin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

p5pRT · 2003-10-07T17:49:36Z

From berikv@xs4all.nl

Created by berikv@xs4all.nl

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..

The code generates thesame results on at least 4 machines.
I've tested on:
- Fully updated Gentoo/GNU/Linux (this machine)
- FreeBSD 4.7-RELEASE-p13 with perl5 (revision 5.0 version 6 subversion 1)
- FreeBSD 4.7-RELEASE-p21 with perl5 (revision 5.0 version 6 subversion 1)

Not having this problem on:
- FreeBSD 4.2-RELEASE with perl5 (revision 5.0 version 6 subversion 1)
- BSD/OS 4.1 BSDI with perl5 (revision 5.0 version 6 subversion 1)

Hope i've supplied enough information.

Kind Regards,

Berik Visschers <berikv@xs4all.nl>,
XS4ALL Internet BV.

Perl Info


Flags:
    category=library
    severity=high

Site configuration information for perl v5.8.1:

Configured by berikv at Tue Oct  7 12:09:13 CEST 2003.

Summary of my perl5 (revision 5.0 version 8 subversion 1) configuration:
  Platform:
    osname=linux, osvers=2.4.20-gentoo-r6, archname=i686-linux
    uname='linux dhcp308 2.4.20-gentoo-r6 #4 fri aug 29 23:29:40 cest 2003 i686 intel(r) celeron(r) cpu 1.80ghz genuineintel gnulinux '
    config_args='-des -Darchname=i686-linux -Dcc=gcc -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr -Dlocincpth=  -Doptimize=-march=pentium3 -O3 -pipe -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Dscriptdir=/usr/bin -Dman3ext=3pm -Dcf_by=Gentoo -Ud_csh -Di_gdbm -Di_db -Di_ndbm'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-march=pentium3 -O3 -pipe',
    cppflags='-DPERL5 -fno-strict-aliasing'
    ccversion='', gccversion='3.3.1 20030916 (Gentoo Linux 3.3.1-r4, propolice)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lpthread -lnsl -lndbm -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc
    perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
    libc=/lib/libc-2.3.2.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.3.2'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.1:
    /etc/perl
    /usr/lib/perl5/site_perl/5.8.1/i686-linux
    /usr/lib/perl5/site_perl/5.8.1
    /usr/lib/perl5/site_perl/5.8.0/i686-linux
    /usr/lib/perl5/site_perl/5.8.0
    /usr/lib/perl5/site_perl
    /usr/lib/perl5/vendor_perl/5.8.1/i686-linux
    /usr/lib/perl5/vendor_perl/5.8.1
    /usr/lib/perl5/vendor_perl/5.8.0/i686-linux
    /usr/lib/perl5/vendor_perl/5.8.0
    /usr/lib/perl5/vendor_perl
    /usr/lib/perl5/5.8.1/i686-linux
    /usr/lib/perl5/5.8.1
    /usr/local/lib/site_perl
    /usr/lib/perl5/site_perl/5.8.0/i686-linux
    /usr/lib/perl5/site_perl/5.8.0
    .


Environment for perl v5.8.1:
    HOME=/home/berikv
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/afsws/bin:/etc/afs/afsws:/usr/i686-pc-linux-gnu/gcc-bin/3.3:/usr/X11R6/bin:/opt/blackdown-jdk-1.4.1/bin:/opt/blackdown-jdk-1.4.1/jre/bin:/usr/qt/3/bin:/usr/kde/3.1/bin:/usr/qt/2/bin:/usr/games/bin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

p5pRT · 2003-10-09T20:44:03Z

From @nwc10

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)

Nicholas Clark

p5pRT · 2003-10-17T23:21:09Z

From @iabyn

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.

p5pRT · 2004-11-05T15:22:55Z

From @smpeters

gdb seems to put the blame on Storable...

#0 0x4001dd78 in free_context (cxt=0x8156630) at Storable.xs:1506
1506 stcxt_t *prev = (stcxt_t *)(cxt->prev ?
SvPVX(SvRV(cxt->prev)) : 0);
(gdb) bt
#0 0x4001dd78 in free_context (cxt=0x8156630) at Storable.xs:1506
#1 0x40024111 in do_store (f=0x814ae88, sv=0x0, optype=1, network_order=0,
res=0x0) at Storable.xs:3656
#2 0x400241aa in pstore (f=0x0, sv=0x0) at Storable.xs:3672
#3 0x40029833 in XS_Storable_pstore (cv=0x81f1848) at Storable.xs:6180
#4 0x080c0384 in Perl_pp_entersub () at pp_hot.c:2826
#5 0x080b8878 in Perl_runops_standard () at run.c:37
#6 0x080627fe in S_call_body (myop=0xbffff2d0, is_eval=0) at perl.c:2154
#7 0x08062649 in Perl_call_sv (sv=0x1, flags=150) at perl.c:2073
#8 0x080c8f08 in Perl_sv_clear (sv=0x8144054) at sv.c:5896
#9 0x080c976a in Perl_sv_free2 (sv=0x8144054) at sv.c:6164
#10 0x080c12ad in S_visit (f=0x80c12d0 <do_clean_objs>, flags=524288,
mask=524288) at sv.c:347
#11 0x080c143b in Perl_sv_clean_objs () at sv.c:441
#12 0x08060759 in perl_destruct (my_perl=0x8143e10) at perl.c:436
#13 0x0805e42d in main (argc=0, argv=0x0, env=0xbffff510) at perlmain.c:97

p5pRT · 2004-11-05T15:22:57Z

The RT System itself - Status changed from 'new' to 'open'

p5pRT · 2006-05-30T16:21:08Z

From @mjdominus

Created by @mjdominus

This program dumps core:

use Memoize;
use Memoize::Storable;
$Memoize::Storable::Verbose = 1;

sub f {
my ($arg) = @_;
return (1, 2);
}

tie my %cache => 'Memoize::Storable', 'cache';
memoize 'f', LIST_CACHE => [HASH => \%cache];

print f('arg');

The output:

plover% perl m.pl
Memoize::Storable::TIEHASH(cache, )
Memoize::Storable::EXISTS(arg)
Memoize::Storable::STORE(arg ARRAY(0x81be800))
Memoize::Storable::FETCH(arg)
12Memoize::Storable::DESTROY()
Segmentation fault (core dumped)

The backtrace from the core file is:

#0 0x0809c844 in Perl_av_undef () at eval.c:41
#1 0x401c4697 in clean_retrieve_context ()
from /usr/local/lib/perl5/5.8.0/i586-linux/auto/Storable/Storable.so
#2 0x401c92ef in do_store ()
from /usr/local/lib/perl5/5.8.0/i586-linux/auto/Storable/Storable.so
#3 0x401c93f7 in pstore ()
from /usr/local/lib/perl5/5.8.0/i586-linux/auto/Storable/Storable.so
#4 0x401ccee4 in XS_Storable_pstore ()
from /usr/local/lib/perl5/5.8.0/i586-linux/auto/Storable/Storable.so
#5 0x080a39a3 in Perl_pp_entersub () at eval.c:41
#6 0x0809dbc2 in Perl_runops_standard () at eval.c:41
#7 0x0805f9f0 in S_call_body () at eval.c:41
#8 0x0805f7ca in Perl_call_sv () at eval.c:41
#9 0x080aa3c1 in Perl_sv_clear () at eval.c:41
#10 0x080aa8c9 in Perl_sv_free () at eval.c:41
#11 0x080a46f4 in S_visit () at eval.c:41
#12 0x080a4807 in Perl_sv_clean_objs () at eval.c:41
#13 0x0805d5b4 in perl_destruct () at eval.c:41
#14 0x0805c934 in main () at eval.c:41
#15 0x40070336 in __libc_start_main (main=0x805c8a0 <main>, argc=2,
ubp_av=0xbffff82c, init=0x805ba58 <_init>, fini=0x80f5800 <_fini>,
rtld_fini=0x4000d2fc <_dl_fini>, stack_end=0xbffff81c)
at ../sysdeps/generic/libc-start.c:129

I wanted to rule out the possibility of Memoize::Storable doing
something weird, so I added some debugging lines to the relevant
part as follows:

sub DESTROY {
require Carp if $Verbose;
my $self= shift;
print STDERR "Memoize::Storable::DESTROY(@_)\n" if $Verbose;
if ($self->{OPTIONS}{'nstore'}) {
Storable::nstore($self->{H}, $self->{FILENAME});
} else {
print STDERR "Memoize::Storable::DESTROY about to write $self->{H} to file $self->{FILENAME}\n";
use Data::Dumper;
print Dumper($self->{H});
Storable::store($self->{H}, $self->{FILENAME});
print STDERR "Memoize::Storable::DESTROY finished writing $self->{H} to file '$self->{FILENAME}'\n";
}
}

The output is now:

Memoize::Storable::TIEHASH(cache, )
Memoize::Storable::EXISTS(arg)
Memoize::Storable::STORE(arg ARRAY(0x81fff5c))
Memoize::Storable::FETCH(arg)
12Memoize::Storable::DESTROY()
Memoize::Storable::DESTROY about to write HASH(0x8113f74) to file cache
$VAR1 = {
'arg' => [
1,
2
]
};
Segmentation fault (core dumped)

Perl Info


Flags:
    category=library
    severity=high

Site configuration information for perl v5.8.0:

Configured by mjd at Thu Apr 17 11:57:37 EDT 2003.

Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.4.2-2, archname=i586-linux
    uname='linux plover.com 2.4.2-2 #1 sun apr 8 19:37:14 edt 2001 i586 unknown '
    config_args='-des'
    hint=previous, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
    optimize='-O2',
    cppflags='-fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm'
    ccversion='', gccversion='2.96 20000731 (Red Hat Linux 7.1 2.96-81)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lndbm -lgdbm -ldl -lm -lc -lcrypt -lutil
    perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil
    libc=/lib/libc-2.2.2.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.2.4'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.0:
    /usr/local/lib/perl5/5.8.0/i586-linux
    /usr/local/lib/perl5/5.8.0
    /usr/local/lib/perl5/site_perl/5.8.0/i586-linux
    /usr/local/lib/perl5/site_perl/5.8.0
    /usr/local/lib/perl5/site_perl/5.7.3
    /usr/local/lib/perl5/site_perl/5.7.2
    /usr/local/lib/perl5/site_perl/5.6.1
    /usr/local/lib/perl5/site_perl/5.6.0
    /usr/local/lib/perl5/site_perl
    .


Environment for perl v5.8.0:
    HOME=/home/mjd
    LANG=C
    LANGUAGE (unset)
    LD_LIBRARY_PATH=/lib:/usr/lib:/usr/X11R6/lib
    LOGDIR (unset)
    PATH=/home/mjd/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/games:/sbin:/usr/sbin:/usr/local/bin/X11R6:/usr/local/bin/mh:/data/mysql/bin:/usr/local/bin/pbm:/usr/local/bin/ezmlm:/home/mjd/TPI/bin:/usr/local/teTeX/bin:/usr/local/mysql/bin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

p5pRT · 2006-06-01T15:38:07Z

From @smpeters

On Tue, May 30, 2006 at 09:21:09AM -0700, Mark-Jason Dominus wrote:

# New Ticket Created by Mark-Jason Dominus
# Please include the string: [perl #39246]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=39246 >

This is a bug report for perl from mjd@plover.com,
generated with the help of perlbug 1.34 running under perl v5.8.0.

-----------------------------------------------------------------
[Please enter your report here]

This program dumps core:
    use Memoize;
    use Memoize&#8203;::Storable;
    $Memoize&#8203;::Storable&#8203;::Verbose = 1;

    sub f \{
        my $$arg$ = @&#8203;\_;
        return $1\, 2$;
    \}

    tie my %cache => 'Memoize&#8203;::Storable'\, 'cache';
    memoize 'f'\, LIST\_CACHE => \[HASH => \\%cache\];

    print f$'arg'$;
The output:
    plover% perl m\.pl
    Memoize&#8203;::Storable&#8203;::TIEHASH$cache\, $
    Memoize&#8203;::Storable&#8203;::EXISTS$arg$
    Memoize&#8203;::Storable&#8203;::STORE$arg ARRAY\(0x81be800$\)
    Memoize&#8203;::Storable&#8203;::FETCH$arg$
    12Memoize&#8203;::Storable&#8203;::DESTROY
    Segmentation fault $core dumped$

I believe that this bug is related to or a duplaicate of
RT #21436: Memoize::Storable seems to cause SEGVs

Steve Peters
steve@fisharerojo.org

p5pRT · 2006-06-01T15:38:10Z

The RT System itself - Status changed from 'new' to 'open'

p5pRT · 2006-06-01T18:19:31Z

From @smpeters

On Thu, Jun 01, 2006 at 10:37:25AM -0500, Steve Peters wrote:

On Tue, May 30, 2006 at 09:21:09AM -0700, Mark-Jason Dominus wrote:
# New Ticket Created by Mark-Jason Dominus
# Please include the string: [perl #39246]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=39246 >

This is a bug report for perl from mjd@plover.com,
generated with the help of perlbug 1.34 running under perl v5.8.0.

-----------------------------------------------------------------
[Please enter your report here]

This program dumps core:
    use Memoize;
    use Memoize&#8203;::Storable;
    $Memoize&#8203;::Storable&#8203;::Verbose = 1;

    sub f \{
        my $$arg$ = @&#8203;\_;
        return $1\, 2$;
    \}

    tie my %cache => 'Memoize&#8203;::Storable'\, 'cache';
    memoize 'f'\, LIST\_CACHE => \[HASH => \\%cache\];

    print f$'arg'$;
The output:
    plover% perl m\.pl
    Memoize&#8203;::Storable&#8203;::TIEHASH$cache\, $
    Memoize&#8203;::Storable&#8203;::EXISTS$arg$
    Memoize&#8203;::Storable&#8203;::STORE$arg ARRAY\(0x81be800$\)
    Memoize&#8203;::Storable&#8203;::FETCH$arg$
    12Memoize&#8203;::Storable&#8203;::DESTROY
    Segmentation fault $core dumped$
I believe that this bug is related to or a duplaicate of
RT #21436: Memoize::Storable seems to cause SEGVs

Interestingly, this appears to be fixed in bleadperl. My best guess is
that the problems in Storable found by the Coverity scans seem to have
fixed this problem.

Abhijit, is this a good point for a new Storable release?

Steve Peters
steve@fisharerojo.org

p5pRT · 2006-06-01T18:30:11Z

@smpeters - Status changed from 'open' to 'resolved'

p5pRT · 2006-06-01T19:01:40Z

From @andk

On Thu, 1 Jun 2006 13:20:07 -0500, Steve Peters <steve@fisharerojo.org> said:

> Interestingly, this appears to be fixed in bleadperl. My best guess is
> that the problems in Storable found by the Coverity scans seem to have
> fixed this problem.

Unfortunately, I cannot confirm that it's fixed. Seems to be a
Heisenbug then. Between patch 20000 and bleadperl I have 39 perls that
return true on MJD's example program and 237 that segfault. Ahh, I
see, we can summarize if you accept that I do have only about 270 perl
in that interval:

20373-22682 ok
23023 not ok
23300-23606 ok
23769-24439 not ok
24471-24489 ok
24496-24978 not ok
25143 ok
25229-25414 not ok
25416 ok
25429-25430 not ok
25439 ok
25459 not ok
25532-25621 ok
25651-26372 not ok
26376-26393 ok
26399-26789 not ok
26796 ok
26813-27242 not ok
27743-27356 ok
27264 not ok
27267-27276 ok
27301-28338 not ok

I tried to filter on debugging perls and threaded perls then to
discover that I cannot discover any pattern. So I'd say Heisenbug.

--
andreas

p5pRT · 2006-06-01T19:29:24Z

From @smpeters

On Thu, Jun 01, 2006 at 09:00:50PM +0200, Andreas J. Koenig wrote:

On Thu, 1 Jun 2006 13:20:07 -0500, Steve Peters <steve@fisharerojo.org> said:

Interestingly, this appears to be fixed in bleadperl. My best guess is
that the problems in Storable found by the Coverity scans seem to have
fixed this problem.

Unfortunately, I cannot confirm that it's fixed. Seems to be a
Heisenbug then. Between patch 20000 and bleadperl I have 39 perls that
return true on MJD's example program and 237 that segfault. Ahh, I
see, we can summarize if you accept that I do have only about 270 perl
in that interval:

20373-22682 ok
23023 not ok
23300-23606 ok
23769-24439 not ok
24471-24489 ok
24496-24978 not ok
25143 ok
25229-25414 not ok
25416 ok
25429-25430 not ok
25439 ok
25459 not ok
25532-25621 ok
25651-26372 not ok
26376-26393 ok
26399-26789 not ok
26796 ok
26813-27242 not ok
27743-27356 ok
27264 not ok
27267-27276 ok
27301-28338 not ok

I tried to filter on debugging perls and threaded perls then to
discover that I cannot discover any pattern. So I'd say Heisenbug.

Splendid! Let me re-open it.

Steve Peters
steve@fisharerojo.org

p5pRT · 2006-06-01T19:29:53Z

@smpeters - Status changed from 'resolved' to 'open'

p5pRT · 2006-06-01T23:30:15Z

From @mjdominus

Andreas Koenig:

I tried to filter on debugging perls and threaded perls then to
discover that I cannot discover any pattern. So I'd say Heisenbug.

That was my guess as well from my (very limited) attempts to produce a
simpler test case that involved only Storable. I gave up early
because the behavior seemed so delicately poised at the boundary of
two different behaviors. I am glad to have your confirmation of this.
Thanks for investigating.

p5pRT · 2010-12-12T21:09:26Z

From @cpansprout

On Fri Oct 17 16:21:09 2003, davem wrote:

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.

If Memoize::Storable were to fire its destructors preemptively in an END
block, that would eliminate the crash (untested).
Should Storable itself also be made more resilient?

p5pRT · 2017-12-06T00:06:40Z

From @tonycoz

On Sun, 12 Dec 2010 13:09:26 -0800, sprout wrote:

On Fri Oct 17 16:21:09 2003, davem wrote:

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.

If Memoize::Storable were to fire its destructors preemptively in an END
block, that would eliminate the crash (untested).
Should Storable itself also be made more resilient?

This may have been fixed by f17010d.

Tony

p5pRT closed this as completed Jun 1, 2006

p5pRT added Severity High distro-Linux hasCoreDump type-library labels Oct 18, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Core dump in Storable::store #8468

Core dump in Storable::store #8468

p5pRT commented May 30, 2006

p5pRT commented Mar 3, 2003

p5pRT commented Oct 7, 2003

p5pRT commented Oct 9, 2003

p5pRT commented Oct 17, 2003

p5pRT commented Nov 5, 2004

p5pRT commented Nov 5, 2004

p5pRT commented May 30, 2006

p5pRT commented Jun 1, 2006

p5pRT commented Jun 1, 2006

p5pRT commented Jun 1, 2006

p5pRT commented Jun 1, 2006

p5pRT commented Jun 1, 2006

p5pRT commented Jun 1, 2006

p5pRT commented Jun 1, 2006

p5pRT commented Jun 1, 2006

p5pRT commented Dec 12, 2010

p5pRT commented Dec 6, 2017

Core dump in Storable::store #8468

Core dump in Storable::store #8468

Comments

p5pRT commented May 30, 2006

p5pRT commented Mar 3, 2003

From @nwc10

Created by @nwc10

p5pRT commented Oct 7, 2003

From berikv@xs4all.nl

Created by berikv@xs4all.nl

p5pRT commented Oct 9, 2003

From @nwc10

p5pRT commented Oct 17, 2003

From @iabyn

p5pRT commented Nov 5, 2004

From @smpeters

p5pRT commented Nov 5, 2004

p5pRT commented May 30, 2006

From @mjdominus

Created by @mjdominus

p5pRT commented Jun 1, 2006

From @smpeters

p5pRT commented Jun 1, 2006

p5pRT commented Jun 1, 2006

From @smpeters

p5pRT commented Jun 1, 2006

p5pRT commented Jun 1, 2006

From @andk

p5pRT commented Jun 1, 2006

From @smpeters

p5pRT commented Jun 1, 2006

p5pRT commented Jun 1, 2006

From @mjdominus

p5pRT commented Dec 12, 2010

From @cpansprout

p5pRT commented Dec 6, 2017

From @tonycoz