I ran valgrind on my project which is using libxml++ 2.40 (though I see very similar code in 2.91) and it's
reporting a "definite" mem leak in libxml++. I've narrowed the problem to a small standalone app (below and
attached). Looks like the leak occurs when an attribute is removed after it's obtained. If either of these
is not done (ie. attribute not obtained or not removed) then no reported leak.
Repro code:
-----
#include <assert.h>
#include <libxml++/libxml++.h>
#include <iostream>
#include <string>
int main()
{
std::cout << "Begin." << std::endl;
xmlpp::DomParser parser;
const std::string strXml("\
<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n\
<foo a=\"b\" >\n\
</foo>"
);
parser.parse_memory(strXml);
// Get root node
xmlpp::Node * pRootNode = parser.get_document()->get_root_node();
assert(pRootNode);
// Get attribute
xmlpp::Element * pElementNode = dynamic_cast<xmlpp::Element*>(pRootNode);
assert(pElementNode);
// !!! No mem leak reported if next line excluded
const std::string strAttributeValue(pElementNode->get_attribute_value("a") );
// Remove attribute
// !!! No mem leak reported if next line excluded
pElementNode->remove_attribute("a");
std::cout << "End." << std::endl;
}
-----
Compile with g++ -g ... and run with valgrind --leak-check=yes ...
Relevant part of valgrind output:
-----
==26695== 16 bytes in 1 blocks are definitely lost in loss record 105 of 254
==26695== at 0x4C30A62: operator new(unsigned long) (vg_replace_malloc.c:344)
==26695== by 0x4E76FA4: xmlpp::Node::create_wrapper(_xmlNode*) (node.cc:654)
==26695== by 0x4E731BE: xmlpp::Element::get_attribute(Glib::ustring const&, Glib::ustring const&) const
(element.cc:61)
==26695== by 0x4E73240: xmlpp::Element::get_attribute_value(Glib::ustring const&, Glib::ustring const&)
const (element.cc:70)
==26695== by 0x401469: main (main.cpp:28)
-----
TIA!Attachment:
main.cpp
Description: Text Data