libxml memory leak ?

Hi All,

I was tracking a memory leak and ended up with a very simple
libxml
program that leaks according to valgrind (I reproduced it
with libxml
2.6.26). 
Could someone, please, have a look at the attached c file
and tell me if
I am doing something wrong? If not, I will create a bug
report for it.
The valgrind report is also attached.

Thanks,
Christophe

-- 
Christophe Barbe - Software Engineer
Objective Systems, Inc.
REAL WORLD ASN.1 AND XML SOLUTIONS
Tel: +1 (484) 875-9841
Fax: +1 (484) 875-9830
Toll-free: (877) 307-6855 (USA only)
http://www.obj-sys.com
==6293== Memcheck, a memory error detector.
==6293== Copyright (C) 2002-2005, and GNU GPL'd, by Julian
Seward et al.
==6293== Using LibVEX rev 1471, a library for dynamic binary
translation.
==6293== Copyright (C) 2004-2005, and GNU GPL'd, by
OpenWorks LLP.
==6293== Using valgrind-3.1.0-Debian, a dynamic binary
instrumentation framework.
==6293== Copyright (C) 2000-2005, and GNU GPL'd, by Julian
Seward et al.
==6293== For more details, rerun with: -v
==6293== 
==6293== 
==6293== ERROR SUMMARY: 0 errors from 0 contexts
(suppressed: 19 from 1)
==6293== malloc/free: in use at exit: 470 bytes in 19
blocks.
==6293== malloc/free: 30 allocs, 11 frees, 5,185 bytes
allocated.
==6293== For counts of detected errors, rerun with: -v
==6293== searching for pointers to 19 not-freed blocks.
==6293== checked 121,364 bytes.
==6293== 
==6293== 48 bytes in 2 blocks are still reachable in loss
record 1 of 4
==6293==    at 0x401C422: malloc (vg_replace_malloc.c:149)
==6293==    by 0x40B784E: xmlNewMutex (in
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x40B6A06: xmlInitGlobals (in
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x406727B: xmlInitParser (in
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x4115226: (within
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x4116921: xmlSaveFormatFileEnc (in
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x41169A4: xmlSaveFormatFile (in
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x8048568: main (in
/home/christophe/data/tmp/libxml-leak/tester)
==6293== 
==6293== 
==6293== 62 bytes in 8 blocks are still reachable in loss
record 2 of 4
==6293==    at 0x401C422: malloc (vg_replace_malloc.c:149)
==6293==    by 0x40B9FAF: xmlStrndup (in
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x40BA026: xmlStrdup (in
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x404E01B: xmlNewCharEncodingHandler (in
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x404E134: xmlInitCharEncodingHandlers (in
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x406728A: xmlInitParser (in
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x4115226: (within
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x4116921: xmlSaveFormatFileEnc (in
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x41169A4: xmlSaveFormatFile (in
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x8048568: main (in
/home/christophe/data/tmp/libxml-leak/tester)
==6293== 
==6293== 
==6293== 160 bytes in 8 blocks are still reachable in loss
record 3 of 4
==6293==    at 0x401C422: malloc (vg_replace_malloc.c:149)
==6293==    by 0x404E030: xmlNewCharEncodingHandler (in
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x404E134: xmlInitCharEncodingHandlers (in
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x406728A: xmlInitParser (in
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x4115226: (within
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x4116921: xmlSaveFormatFileEnc (in
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x41169A4: xmlSaveFormatFile (in
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x8048568: main (in
/home/christophe/data/tmp/libxml-leak/tester)
==6293== 
==6293== 
==6293== 200 bytes in 1 blocks are still reachable in loss
record 4 of 4
==6293==    at 0x401C422: malloc (vg_replace_malloc.c:149)
==6293==    by 0x404E0E6: xmlInitCharEncodingHandlers (in
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x406728A: xmlInitParser (in
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x4115226: (within
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x4116921: xmlSaveFormatFileEnc (in
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x41169A4: xmlSaveFormatFile (in
/usr/lib/libxml2.so.2.6.24)
==6293==    by 0x8048568: main (in
/home/christophe/data/tmp/libxml-leak/tester)
==6293== 
==6293== LEAK SUMMARY:
==6293==    definitely lost: 0 bytes in 0 blocks.
==6293==      possibly lost: 0 bytes in 0 blocks.
==6293==    still reachable: 470 bytes in 19 blocks.
==6293==         suppressed: 0 bytes in 0 blocks.
_______________________________________________
xml mailing list, project page  http://xmlsoft.org/
xmlgnome.org
http://mai
l.gnome.org/mailman/listinfo/xml

On Fri, Jul 28, 2006 at 02:25:41PM -0400, christophe barbe
<cbarbeobj-sys.com> wrote:
> Hi All,
> 
> I was tracking a memory leak and ended up with a very
simple libxml
> program that leaks according to valgrind (I reproduced
it with libxml
> 2.6.26). 
> Could someone, please, have a look at the attached c
file and tell me if
> I am doing something wrong? If not, I will create a bug
report for it.
> The valgrind report is also attached.

You want to add a call to xmlCleanupParser() at the end of
your
program.

Mike
_______________________________________________
xml mailing list, project page  http://xmlsoft.org/
xmlgnome.org
http://mai
l.gnome.org/mailman/listinfo/xml

Thanks Mike,

I was not expecting to have to do that as I was not parsing
any document
but it fixes the memory leak.

Christophe

On Fri, 2006-07-28 at 23:14 +0200, Mike Hommey wrote:
> On Fri, Jul 28, 2006 at 02:25:41PM -0400, christophe
barbe <cbarbeobj-sys.com> wrote:
> > Hi All,
> > 
> > I was tracking a memory leak and ended up with a
very simple libxml
> > program that leaks according to valgrind (I
reproduced it with libxml
> > 2.6.26). 
> > Could someone, please, have a look at the attached
c file and tell me if
> > I am doing something wrong? If not, I will create
a bug report for it.
> > The valgrind report is also attached.
> 
> You want to add a call to xmlCleanupParser() at the end
of your
> program.
> 
> Mike
-- 
Christophe Barbe - Software Engineer
Objective Systems, Inc.
REAL WORLD ASN.1 AND XML SOLUTIONS
Tel: +1 (484) 875-9841
Fax: +1 (484) 875-9830
Toll-free: (877) 307-6855 (USA only)
http://www.obj-sys.com

_______________________________________________
xml mailing list, project page  http://xmlsoft.org/
xmlgnome.org
http://mai
l.gnome.org/mailman/listinfo/xml

christophe barbe wrote:
> Thanks Mike,
> 
> I was not expecting to have to do that as I was not
parsing any document
> but it fixes the memory leak.
> 
> Christophe
> 
> On Fri, 2006-07-28 at 23:14 +0200, Mike Hommey wrote:
>> On Fri, Jul 28, 2006 at 02:25:41PM -0400,
christophe barbe <cbarbeobj-sys.com> wrote:
>>> Hi All,
>>>
>>> I was tracking a memory leak and ended up with
a very simple libxml
>>> program that leaks according to valgrind (I
reproduced it with libxml
>>> 2.6.26). 
>>> Could someone, please, have a look at the
attached c file and tell me if
>>> I am doing something wrong? If not, I will
create a bug report for it.
>>> The valgrind report is also attached.
>> You want to add a call to xmlCleanupParser() at the
end of your
>> program.
>>
>> Mike

Also note that it is not technically a leak, as the memory
is still
reachable. You would have the same effect using a flex
scanner in a
program - it allocates a buffer on first use, which is never
automagically cleaned up (but it's reused each call to the
scanner).
There is no pressing need to 'fix' these in a standalone
program
(although if it's as easy to resolve as in this case, it is
of course
nice to get a clean bill of health from valgrind).
_______________________________________________
xml mailing list, project page  http://xmlsoft.org/
xmlgnome.org
http://mai
l.gnome.org/mailman/listinfo/xml