I'm writing a program using libxml++2.6 version 2.34.1 on Ubuntu 12.10 64bit and according to valgrind there is a memory leak.
The program is simple:
#include <libxml++/libxml++.h>
#include <iostream>
int main(int argc, char* argv[])
{
try
{
xmlpp::DomParser parser("example.xml");
}
catch(...)
{
std::cout << "Exception caught" << std::endl;
}
return 0;
}
==14723== HEAP SUMMARY:
==14723== in use at exit: 966 bytes in 20 blocks
==14723== total heap usage: 206 allocs, 186 frees, 50,191 bytes allocated
==14723==
==14723== Searching for pointers to 20 not-freed blocks
==14723== Checked 332,592 bytes
==14723==
==14723== 104 bytes in 1 blocks are still reachable in loss record 19 of 20
==14723== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14723== by 0x682BC1A: xmlNewRMutex (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.7.8)
==14723== by 0x687E194: ??? (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.7.8)
==14723== by 0x687E214: xmlDictCreate (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.7.8)
==14723== by 0x67B9774: xmlInitParserCtxt (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.7.8)
==14723== by 0x67B9BCB: xmlNewParserCtxt (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.7.8)
==14723== by 0x67CCB0D: xmlCreateURLParserCtxt (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.7.8)
==14723== by 0x510F32E: xmlpp::DomParser::parse_file(Glib::ustring const&) (in /usr/lib/libxml++-2.6.so.2.0.7)
==14723== by 0x510F9FD: xmlpp::DomParser::DomParser(Glib::ustring const&, bool) (in /usr/lib/libxml++-2.6.so.2.0.7)
==14723== by 0x4023E2: main (MNEntryPoint.cpp:200)
==14723==
==14723== LEAK SUMMARY:
==14723== definitely lost: 0 bytes in 0 blocks
==14723== indirectly lost: 0 bytes in 0 blocks
==14723== possibly lost: 0 bytes in 0 blocks
==14723== still reachable: 104 bytes in 1 blocks
==14723== suppressed: 862 bytes in 19 blocks
==14723==
==14723== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
==14723==
==14723== 1 errors in context 1 of 1:
==14723== Conditional jump or move depends on uninitialised value(s)
==14723== at 0x78564E0: inflateReset2 (in /lib/x86_64-linux-gnu/libz.so.1.2.3.4)
==14723== by 0x78565D8: inflateInit2_ (in /lib/x86_64-linux-gnu/libz.so.1.2.3.4)
==14723== by 0x7850323: ??? (in /lib/x86_64-linux-gnu/libz.so.1.2.3.4)
==14723== by 0x67E38E5: ??? (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.7.8)
==14723== by 0x67E4011: __xmlParserInputBufferCreateFilename (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.7.8)
==14723== by 0x67B92B1: xmlNewInputFromFile (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.7.8)
==14723== by 0x67CCB35: xmlCreateURLParserCtxt (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.7.8)
==14723== by 0x510F32E: xmlpp::DomParser::parse_file(Glib::ustring const&) (in /usr/lib/libxml++-2.6.so.2.0.7)
==14723== by 0x510F9FD: xmlpp::DomParser::DomParser(Glib::ustring const&, bool) (in /usr/lib/libxml++-2.6.so.2.0.7)
==14723== by 0x4023E2: main (MNEntryPoint.cpp:200)
==14723== Uninitialised value was created by a heap allocation
==14723== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14723== by 0x78565B6: inflateInit2_ (in /lib/x86_64-linux-gnu/libz.so.1.2.3.4)
==14723== by 0x7850323: ??? (in /lib/x86_64-linux-gnu/libz.so.1.2.3.4)
==14723== by 0x67E38E5: ??? (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.7.8)
==14723== by 0x67E4011: __xmlParserInputBufferCreateFilename (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.7.8)
==14723== by 0x67B92B1: xmlNewInputFromFile (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.7.8)
==14723== by 0x67CCB35: xmlCreateURLParserCtxt (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.7.8)
==14723== by 0x510F32E: xmlpp::DomParser::parse_file(Glib::ustring const&) (in /usr/lib/libxml++-2.6.so.2.0.7)
==14723== by 0x510F9FD: xmlpp::DomParser::DomParser(Glib::ustring const&, bool) (in /usr/lib/libxml++-2.6.so.2.0.7)
==14723== by 0x4023E2: main (MNEntryPoint.cpp:200)
It comes from the method xmlpp::DomParser::parse_file(Glib::ustring const&), but this bug has apparently already been reported and patched years ago:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469809
I'm pretty sure that the version on Quantal is the patched one without the bug, but I don't understand why I get this memory leak.