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