Quoting ikegami's comment because I couldn't formulate it better:
It's a bug in Perl or in an XS module. A variable should be freed when its reference count reaches zero, but something attempted to decrement a variable's reference count when it was already zero.
As the output of valgrind
shows, in this specific instance, the problem is in XML::LibXML
.
I reckon that updating XML::LibXML
, as suggested by Sinan Ünür as soon as the problem will be understood and fixed is the way to go. Unfortunately, updating from 2.0001 (Debian stable version) to 2.0116 (CPAN version) did not fix it.
What did fix the problem, finally, was to modify SetOfThings::explode
so that it creates a new instance and copies the attributes it needs rather than cloning the current instance and deleting the attributes is doesn't need:
sub explode {
my $self = shift;
my $new = __PACKAGE__->new;
$new->some_attribute('whatever');
$new->set_of_things( map { $_->explode } $self->constraints );
return $new;
}
One of the attributes of the SetOfThings
object that was cloned then deleted was a DOM, which clearly XML::LibXML
did not appreciate. Thanks to this knowledge and the comments posted, I was finally able to reproduce my problem in a very small script and post a bug report:
#!/usr/bin/perl
use strict;
use warnings;
use Clone 'clone';
use XML::LibXML;
my $dom1 = new XML::LibXML::Document;
my $dom2 = clone $dom1;
As pointed out by ikegami, cloning the Perl variable doesn't copy the underlying C structure used by the library. But XML::LibXML
does provide a cloneNode
method, therefore changing the last line to
my $dom2 = $dom1->cloneNode(1)
gives the desired result.