GNOME Bugzilla – Bug 335085
One memory leak, and one potential memory leak.
Last modified: 2006-10-13 10:28:26 UTC
Please describe the problem: The function xmlIOParseDTD is supposed to free the xmlParserInputBufferPtr; however it is possible for the function to return NULL without freeing the buffer. What makes this a problem is that its possible for the function to return NULL and free the buffer. Because the pointer is never set to NULL, its impossible to test whether the pointer was in fact freed. As such, if the pointer ever returned NULL it would be impossible to clean up properly. The function xmlCtxtReadFile might have a memory leak. See the valgrind output below. I haven't investigated further than what valgrind shows. I am calling: xmlFreeDoc(); xmlFreeParserCtxt(); xmlCleanupParser(); None of which appear to cleanup this memory: ==17753== 16 bytes in 1 blocks are still reachable in loss record 1 of 2 ==17753== at 0x1B905301: calloc (vg_replace_malloc.c:176) ==17753== by 0xB07364: _dlerror_run (in /lib/libdl-2.3.4.so) ==17753== by 0xB06E3B: dlsym (in /lib/libdl-2.3.4.so) ==17753== by 0x1B92ECA6: __errno_location (vg_libpthread.c:2127) ==17753== by 0xB0E114: (within /usr/lib/libz.so.1.2.1.2) ==17753== by 0x793FF1: (within /usr/lib/libxml2.so.2.6.16) ==17753== by 0x79404F: (within /usr/lib/libxml2.so.2.6.16) ==17753== by 0x79454A: __xmlParserInputBufferCreateFilename (in /usr/lib/libxml2.so.2.6.16) ==17753== by 0x79465F: xmlParserInputBufferCreateFilename (in /usr/lib/libxml2.so.2.6.16) ==17753== by 0x789F3C: xmlNewInputFromFile (in /usr/lib/libxml2.so.2.6.16) ==17753== by 0x7A6A44: xmlCtxtReadFile (in /usr/lib/libxml2.so.2.6.16) ==17753== by 0x8048890: main (main.c:129) Steps to reproduce: 1. See above. Actual results: Memory leak. Expected results: Memory freed. Does this happen every time? Yes. Other information: The potential memory leak was confirmed by looking at the source for 2.6.23. The second leak, reported by valgrind was reported on libxml2-2.6.16-6, which is a repackaged Red Hat Enterprise version of the library. The reason I can't confirm the second one is because I only have the source for 2.6.23.
Okay, I cleaned up xmlIOParseDTD() and fixed the documentation, thanks for raising this. W.r.t. your valgrind stack trace it seems to happen when dynamically loading a shared library, I certainly don't see this here, and since the shared library can only be loaded once, any leak here should happen at most one time. Still taht looks suspicious and you should check with your distribution, that doesn't look libxml2 specific. Daniel