After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 335085 - One memory leak, and one potential memory leak.
One memory leak, and one potential memory leak.
Status: RESOLVED FIXED
Product: libxml2
Classification: Platform
Component: general
2.6.22
Other All
: Normal normal
: ---
Assigned To: Daniel Veillard
libxml QA maintainers
Depends on:
Blocks:
 
 
Reported: 2006-03-19 04:56 UTC by ladar
Modified: 2006-10-13 10:28 UTC
See Also:
GNOME target: ---
GNOME version: 2.5/2.6



Description ladar 2006-03-19 04:56:31 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.
Comment 1 Daniel Veillard 2006-10-13 10:28:26 UTC
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