| Subject: | XML::LibXML objects unserialized by retrieve (from Storable) causes segfaults and other memory problems |
| Date: | Tue, 25 Mar 2014 11:50:23 -0400 |
| To: | bug-XML-LibXML [...] rt.cpan.org |
| From: | Jeff <jeff [...] jefftrout.com> |
I’d sent a previous bug about an interaction with libxml2 (https://rt.cpan.org/Ticket/Display.html?id=94149)
and after fixing that up I ran into another problem which may be more a bug for the Storable guys than you guys.
So turns out some xml::libxml objects were getting serialized as part of my app (I’d previously removed other xml::libxml objects, I think because serialize would throw an error, an os upgrade seems to have upgraded perl and allowed it to serialize them (the orig code was written a while ago)).
when the retrieve’d xml::libxml object is destroyed we run into memory errors, usually for me, being a segfault due to accessing invalid memory. If you think this is more a storable bug I’ll file with them.
here’s a small script to induce it:
#/usr/bin/perl
#
use strict;
use XML::LibXML;
use Storable qw(store retrieve);
use Data::Dumper;
if($ARGV[0] eq "1")
{
my $test = new XML::LibXML::Text("tacos");
store($test, "store.data");
print "Now rerun brokeserialize.pl 2\n";
exit;
} else {
my $test = retrieve("store.data");
print Dumper($test);
# this will either work fine (luck) or segfault due to an invalid free.
exit;
}
when run:
jeff@debian:~$ perl brokeserialize.pl 1
Now rerun brokeserialize.pl 2
jeff@debian:~$ valgrind perl brokeserialize.pl 2
==25892== Memcheck, a memory error detector
==25892== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==25892== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==25892== Command: perl brokeserialize.pl 2
==25892==
$VAR1 = bless( do{\(my $o = 9999632)}, 'XML::LibXML::Text' );
==25892== Invalid read of size 4
==25892== at 0x6C7988F: PmmREFCNT_dec (perl-libxml-mm.c:440)
==25892== by 0x6C5DB3E: XS_XML__LibXML__Node_DESTROY (LibXML.xs:4147)
==25892== by 0x4EE764B: Perl_pp_entersub (in /usr/lib/libperl.so.5.14.2)
==25892== by 0x4E7AAD0: Perl_call_sv (in /usr/lib/libperl.so.5.14.2)
==25892== by 0x4EEDB18: Perl_sv_clear (in /usr/lib/libperl.so.5.14.2)
==25892== by 0x4EEE1D1: Perl_sv_free2 (in /usr/lib/libperl.so.5.14.2)
==25892== by 0x4F15C2E: Perl_leave_scope (in /usr/lib/libperl.so.5.14.2)
==25892== by 0x4E79CA4: ??? (in /usr/lib/libperl.so.5.14.2)
==25892== by 0x4E79B50: Perl_my_exit (in /usr/lib/libperl.so.5.14.2)
==25892== by 0x4F21DE3: Perl_pp_exit (in /usr/lib/libperl.so.5.14.2)
==25892== by 0x4EDEC25: Perl_runops_standard (in /usr/lib/libperl.so.5.14.2)
==25892== by 0x4E80754: perl_run (in /usr/lib/libperl.so.5.14.2)
==25892== Address 0x989520 is not stack'd, malloc'd or (recently) free'd
==25892==
==25892==
==25892== Process terminating with default action of signal 11 (SIGSEGV)
==25892== Access not within mapped region at address 0x989520
==25892== at 0x6C7988F: PmmREFCNT_dec (perl-libxml-mm.c:440)
==25892== by 0x6C5DB3E: XS_XML__LibXML__Node_DESTROY (LibXML.xs:4147)
==25892== by 0x4EE764B: Perl_pp_entersub (in /usr/lib/libperl.so.5.14.2)
==25892== by 0x4E7AAD0: Perl_call_sv (in /usr/lib/libperl.so.5.14.2)
==25892== by 0x4EEDB18: Perl_sv_clear (in /usr/lib/libperl.so.5.14.2)
==25892== by 0x4EEE1D1: Perl_sv_free2 (in /usr/lib/libperl.so.5.14.2)
==25892== by 0x4F15C2E: Perl_leave_scope (in /usr/lib/libperl.so.5.14.2)
==25892== by 0x4E79CA4: ??? (in /usr/lib/libperl.so.5.14.2)
==25892== by 0x4E79B50: Perl_my_exit (in /usr/lib/libperl.so.5.14.2)
==25892== by 0x4F21DE3: Perl_pp_exit (in /usr/lib/libperl.so.5.14.2)
==25892== by 0x4EDEC25: Perl_runops_standard (in /usr/lib/libperl.so.5.14.2)
==25892== by 0x4E80754: perl_run (in /usr/lib/libperl.so.5.14.2)
==25892== If you believe this happened as a result of a stack
==25892== overflow in your program's main thread (unlikely but
==25892== possible), you can try to increase the size of the
==25892== main thread stack using the --main-stacksize= flag.
==25892== The main thread stack size used in this run was 8388608.
==25892==
==25892== HEAP SUMMARY:
==25892== in use at exit: 3,694,883 bytes in 50,883 blocks
==25892== total heap usage: 87,309 allocs, 36,426 frees, 6,134,040 bytes allocated
==25892==
==25892== LEAK SUMMARY:
==25892== definitely lost: 2,386 bytes in 53 blocks
==25892== indirectly lost: 2,218 bytes in 27 blocks
==25892== possibly lost: 0 bytes in 0 blocks
==25892== still reachable: 3,690,279 bytes in 50,803 blocks
==25892== suppressed: 0 bytes in 0 blocks
==25892== Rerun with --leak-check=full to see details of leaked memory
==25892==
==25892== For counts of detected and suppressed errors, rerun with: -v
==25892== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
Segmentation fault
--
Jeff Trout <jeff@jefftrout.com>