Skip Menu |

This queue is for tickets about the XML-LibXML CPAN distribution.

Report information
The Basics
Id: 103209
Status: open
Priority: 0/
Queue: XML-LibXML

People
Owner: Nobody in particular
Requestors: mstock [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in:
  • 2.0114
  • 2.0115
  • 2.0116
  • 2.0117
  • 2.0118
Fixed in: 2.0113



Subject: Segfault and double free on Debian Jessie and Ubuntu Utopic Unicorn (probably caused by using replaceNode)
While preparing our code base for Debian Jessie, I ran into segmentation faults and double frees, and I currently assume that this happens when using replaceNode(). I already reported a bug in the Debian issue tracker [1], but haven't received a reply, yet (the segfault.pl version in that bug report doesn't crash as often as the attached one though). The issue also doesn't seem to be completely Debian-specific, as I can also reproduce it on the closely related Ubuntu Utopic Unicorn (14.10) and the slightly older Trusty Tahr (14.04 LTS, but only if I install XML-LibXML from CPAN, the version provided by Ubuntu (2.0108+dfsg-1) seems to work). I also tried various versions of XML-LibXML from CPAN on Debian Jessie and Ubuntu Utopic Unicorn, and it seems that from 2.0114 onwards, the problem is always there. When running the attached files on Debian Jessie (Perl v5.20.2, XMl-LibXML 2.0116+dfsg-1+b1, libxml2 2.9.1+dfsg1-5, all installed from packages, on x86_64), the output looks as follows: $ perl segfault.pl Segmentation fault $ prove Debian_Jessie_double_free.t Debian_Jessie_double_free.t .. *** Error in `/usr/bin/perl': double free or corruption (fasttop): 0x0000000001b012f0 *** Debian_Jessie_double_free.t .. All 1 subtests passed Test Summary Report ------------------- Debian_Jessie_double_free.t (Wstat: 6 Tests: 1 Failed: 0) Non-zero wait status: 6 Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.05 cusr 0.00 csys = 0.07 CPU) Result: FAIL For the segfault, I got this in the syslog: perl[28012] segfault at 40 ip 00007f3a55607ced sp 00007fff2142f6a0 error 4 in LibXML.so[7f3a555bf000+69000] Same, but this time with a local::lib and XML-LibXML 2.0118 installed from CPAN: $ perl segfault.pl *** Error in `perl': double free or corruption (fasttop): 0x0000000001e383e0 *** Aborted $ prove Debian_Jessie_double_free.t Debian_Jessie_double_free.t .. *** Error in `/usr/bin/perl': double free or corruption (fasttop): 0x0000000000ac1140 *** Debian_Jessie_double_free.t .. All 1 subtests passed Test Summary Report ------------------- Debian_Jessie_double_free.t (Wstat: 6 Tests: 1 Failed: 0) Non-zero wait status: 6 Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.05 cusr 0.00 csys = 0.07 CPU) Result: FAIL Nearly the same, but when I ran the commands several times, I noticed that with the version from Debian, I nearly always get a segfault, while with the latest version from CPAN, I nearly always get a double free, and only occasionally a segfault. One thing I noticed while playing with my test scripts is that inlining the get_node() function seems to avoid the crashes. I already spotted #80521 in RT, but since I'm at least not explicitly using any DTD, I don't think that this is the same problem, which is why I'm creating a fresh issue. Kind regards Manfred [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780369
Subject: Debian_Jessie_double_free.t
#!/usr/bin/env perl use strict; use warnings; use Test::More; use XML::LibXML; my $parser = XML::LibXML->new(); my $doc = $parser->parse_string(<<'EOXML'); <?xml version="1.0" encoding="UTF-8"?> <root-element><settings/></root-element> EOXML my $expected = <<'EOXML'; <?xml version="1.0" encoding="UTF-8"?> <root-element><settings><root/></settings></root-element> EOXML my $doc2 = XML::LibXML::Document->new('1.0', 'UTF-8'); my $new_node = $doc2->createElement('root'); $doc2->setDocumentElement($new_node); my $node = get_node($doc); #$doc->adoptNode($new_node); $node->replaceNode($new_node); my $str = $doc->toString(); # diag $str; is($str, $expected); done_testing; sub get_node { my ($doc) = @_; my $parent = $doc->documentElement()->firstChild(); my $node = $doc->createElement('my-settings'); $parent->appendChild($node); return $node; } 1;
Subject: segfault.pl
#!/usr/bin/env perl use strict; use warnings; use XML::LibXML; my $parser = XML::LibXML->new(); my $doc = $parser->parse_string(<<'EOXML'); <?xml version="1.0" encoding="UTF-8"?> <root-element><settings/></root-element> EOXML my $doc2 = XML::LibXML::Document->new('1.0', 'UTF-8'); my $new_node = $doc2->createElement('root'); $doc2->setDocumentElement($new_node); my $node = get_node($doc); #$doc->adoptNode($new_node); $node->replaceNode($new_node); my $str = $doc->toString(); #warn $str; sub get_node { my ($doc) = @_; my $parent = $doc->documentElement()->firstChild(); my $node = $doc->createElement('my-settings'); $parent->appendChild($node); return $node; } 1;
Hi Manfred, this is just to let you know that I got a notification about this bug and that I'll try to investigate it soon. I am able to reproduce a segfault using perl-5.20.1-8.mga5 and perl-XML-LibXML-2.11.600-7.mga5 on Mageia Linux x86-64 5. Regards, -- Shlomi Fish
Hi Manfred, based on your insights in the message, I attached a modified program that does not exhibit the symptoms of the problem (= it does not segfault). What I do is also return $parent. I suspect fixing this problem for code without this workaround will be difficult. Regards, -- Shlomi Fish On Mon Mar 30 14:29:27 2015, SHLOMIF wrote: Show quoted text
> Hi Manfred, > > this is just to let you know that I got a notification about this bug > and that I'll try to investigate it soon. I am able to reproduce a > segfault using perl-5.20.1-8.mga5 and perl-XML-LibXML-2.11.600-7.mga5 > on Mageia Linux x86-64 5. > > Regards, > > -- Shlomi Fish
Subject: XML-LibXML-Test.pl
#!/usr/bin/env perl use strict; use warnings; use Test::More; use XML::LibXML; my $parser = XML::LibXML->new(); my $doc = $parser->parse_string(<<'EOXML'); <?xml version="1.0" encoding="UTF-8"?> <root-element><settings/></root-element> EOXML my $expected = <<'EOXML'; <?xml version="1.0" encoding="UTF-8"?> <root-element><settings><root/></settings></root-element> EOXML my $doc2 = XML::LibXML::Document->new('1.0', 'UTF-8'); my $new_node = $doc2->createElement('root'); $doc2->setDocumentElement($new_node); my ($parent, $node) = get_node($doc); #$doc->adoptNode($new_node); $node->replaceNode($new_node); my $str = $doc->toString(); # diag $str; is($str, $expected); done_testing; sub get_node { my ($doc) = @_; my $parent = $doc->documentElement()->firstChild(); my $node = $doc->createElement('my-settings'); $parent->appendChild($node); return ($parent, $node); } 1;
Hi Shlomi, thanks for your quick response and the workaround :)! Am Mi 01. Apr 2015, 07:09:56, SHLOMIF schrieb: Show quoted text
> based on your insights in the message, I attached a modified program > that does not exhibit the symptoms of the problem (= it does not > segfault). What I do is also return $parent.
With this change, it does not crash anymore on my system, too. I also added the workaround to the more complex code in the actual application, and now these tests don't crash anymore, either :). Show quoted text
> I suspect fixing this problem for code without this workaround will be > difficult.
I see, and I think I can also very roughly imagine why. So for now, I think I can live with the workaround, but I'd still eventually like a proper fix for the case without the workaround. I somehow don't have the best feelings if there is a workaround for a segfault/double free in my/our Perl code ;). Out of curiosity, and since I did not see this problem with 'older' XML-LibXML versions (i.e. 2.0113 and below), I did a 'hg bisect' (never tried that with Mercurial before though ;)) between 1390:65ead9db9cd5 and 1403:57092854dfd2, and in the end, it told me that the first revision with the issue was 1394:001cce143bd8. Best regards Manfred
Hi Manfred, On Wed Apr 01 13:10:54 2015, MSTOCK wrote: Show quoted text
> Hi Shlomi, > > thanks for your quick response and the workaround :)! >
You're welcome. Sorry for the relatively late response now (Passover Seder stuff). Show quoted text
> > Am Mi 01. Apr 2015, 07:09:56, SHLOMIF schrieb:
> > based on your insights in the message, I attached a modified program > > that does not exhibit the symptoms of the problem (= it does not > > segfault). What I do is also return $parent.
> > With this change, it does not crash anymore on my system, too. I also > added the workaround to the more complex code in the actual > application, and now these tests don't crash anymore, either :).
That's great. Show quoted text
> >
> > I suspect fixing this problem for code without this workaround will > > be > > difficult.
> > I see, and I think I can also very roughly imagine why. So for now, I > think I can live with the workaround, but I'd still eventually like a > proper fix for the case without the workaround. I somehow don't have > the best feelings if there is a workaround for a segfault/double free > in my/our Perl code ;). > > Out of curiosity, and since I did not see this problem with 'older' > XML-LibXML versions (i.e. 2.0113 and below), I did a 'hg bisect' > (never tried that with Mercurial before though ;)) between > 1390:65ead9db9cd5 and 1403:57092854dfd2, and in the end, it told me > that the first revision with the issue was 1394:001cce143bd8. >
Thanks for the insights. I'll try to investigate it. Regards, -- Shlomi Fish Show quoted text
> Best regards > Manfred