Home/ Questions/Q 8998623
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-16T00:03:43+00:00

The following code compiles correctly and valgrind reports no leaks: # include <libxml/encoding.h> #

  • 0

The following code compiles correctly and valgrind reports no leaks:

# include <libxml/encoding.h>
# include <libxml/xmlwriter.h>

int main(void) {
  xmlTextWriterPtr XMLWriter = xmlNewTextWriterFilename("example.xml", 0);
  xmlTextWriterStartDocument(XMLWriter, NULL, NULL, NULL);
  xmlTextWriterEndDocument(XMLWriter);
  xmlFreeTextWriter(XMLWriter);
  xmlCleanupParser();
  return 0;
}

-----------------------------------------

==26059== HEAP SUMMARY:
==26059==     in use at exit: 0 bytes in 0 blocks
==26059==   total heap usage: 16 allocs, 16 frees, 4,774 bytes allocated
==26059== 
==26059== All heap blocks were freed -- no leaks are possible

Once the encoding is specified in the xmlNewTextWriterFilename call, however, hilary ensues:

# include <libxml/encoding.h>
# include <libxml/xmlwriter.h>

int main(void) {
  xmlTextWriterPtr XMLWriter = xmlNewTextWriterFilename("example.xml", 0);
  xmlTextWriterStartDocument(XMLWriter, NULL, "UTF-8", NULL);
  xmlTextWriterEndDocument(XMLWriter);
  xmlFreeTextWriter(XMLWriter);
  xmlCleanupParser();
  return 0;
}

-----------------------------------------

==26082== HEAP SUMMARY:
==26082==     in use at exit: 422 bytes in 17 blocks
==26082==   total heap usage: 36 allocs, 19 frees, 9,224 bytes allocated
==26082== 
==26082== 5 bytes in 1 blocks are still reachable in loss record 1 of 17
==26082==    at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082==    by 0x40EC23B: xmlStrndup (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x494942FF: ???
==26082== 
==26082== 6 bytes in 1 blocks are still reachable in loss record 2 of 17
==26082==    at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082==    by 0x40EC23B: xmlStrndup (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x37: ???
==26082== 
==26082== 6 bytes in 1 blocks are still reachable in loss record 3 of 17
==26082==    at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082==    by 0x40EC23B: xmlStrndup (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x39350048: ???
==26082== 
==26082== 7 bytes in 1 blocks are still reachable in loss record 4 of 17
==26082==    at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082==    by 0x40EC23B: xmlStrndup (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x45003630: ???
==26082== 
==26082== 9 bytes in 1 blocks are still reachable in loss record 5 of 17
==26082==    at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082==    by 0x40EC23B: xmlStrndup (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x454C3630: ???
==26082== 
==26082== 9 bytes in 1 blocks are still reachable in loss record 6 of 17
==26082==    at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082==    by 0x40EC23B: xmlStrndup (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x45423630: ???
==26082== 
==26082== 9 bytes in 1 blocks are still reachable in loss record 7 of 17
==26082==    at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082==    by 0x40EC23B: xmlStrndup (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x49494352: ???
==26082== 
==26082== 11 bytes in 1 blocks are still reachable in loss record 8 of 17
==26082==    at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082==    by 0x40EC23B: xmlStrndup (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x39353837: ???
==26082== 
==26082== 20 bytes in 1 blocks are still reachable in loss record 9 of 17
==26082==    at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082==    by 0x406E9D1: xmlNewCharEncodingHandler (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x406EB28: xmlInitCharEncodingHandlers (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x41B54D2: (below main) (libc-start.c:226)
==26082== 
==26082== 20 bytes in 1 blocks are still reachable in loss record 10 of 17
==26082==    at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082==    by 0x406E9D1: xmlNewCharEncodingHandler (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x406EB44: xmlInitCharEncodingHandlers (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x41B54D2: (below main) (libc-start.c:226)
==26082== 
==26082== 20 bytes in 1 blocks are still reachable in loss record 11 of 17
==26082==    at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082==    by 0x406E9D1: xmlNewCharEncodingHandler (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x406EB6C: xmlInitCharEncodingHandlers (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x41B54D2: (below main) (libc-start.c:226)
==26082== 
==26082== 20 bytes in 1 blocks are still reachable in loss record 12 of 17
==26082==    at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082==    by 0x406E9D1: xmlNewCharEncodingHandler (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x406EB94: xmlInitCharEncodingHandlers (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x41B54D2: (below main) (libc-start.c:226)
==26082== 
==26082== 20 bytes in 1 blocks are still reachable in loss record 13 of 17
==26082==    at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082==    by 0x406E9D1: xmlNewCharEncodingHandler (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x406EBB6: xmlInitCharEncodingHandlers (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x41B54D2: (below main) (libc-start.c:226)
==26082== 
==26082== 20 bytes in 1 blocks are still reachable in loss record 14 of 17
==26082==    at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082==    by 0x406E9D1: xmlNewCharEncodingHandler (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x406EBCC: xmlInitCharEncodingHandlers (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x41B54D2: (below main) (libc-start.c:226)
==26082== 
==26082== 20 bytes in 1 blocks are still reachable in loss record 15 of 17
==26082==    at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082==    by 0x406E9D1: xmlNewCharEncodingHandler (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x406EBE2: xmlInitCharEncodingHandlers (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x41B54D2: (below main) (libc-start.c:226)
==26082== 
==26082== 20 bytes in 1 blocks are still reachable in loss record 16 of 17
==26082==    at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082==    by 0x406E9D1: xmlNewCharEncodingHandler (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x406EC02: xmlInitCharEncodingHandlers (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x41B54D2: (below main) (libc-start.c:226)
==26082== 
==26082== 200 bytes in 1 blocks are still reachable in loss record 17 of 17
==26082==    at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082==    by 0x406EABE: xmlInitCharEncodingHandlers (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082==    by 0x41B54D2: (below main) (libc-start.c:226)
==26082== 
==26082== LEAK SUMMARY:
==26082==    definitely lost: 0 bytes in 0 blocks
==26082==    indirectly lost: 0 bytes in 0 blocks
==26082==      possibly lost: 0 bytes in 0 blocks
==26082==    still reachable: 422 bytes in 17 blocks
==26082==         suppressed: 0 bytes in 0 blocks

What do? This is homework stuff – can’t ignore valgrind results.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Add a call to xmlCleanupCharEncodingHandlers() right before the call to xmlCleanupParser().

    On my Mac OS 10.7.5 dev machine (libxml 20703), this fixes the reported “still reachable” leaks in libxml2.

    By the way, ??? means that the debugging symbols for the object file are not available. It can be very helpful when tracking down memory leaks to have this information. The procedure for installing debugging information depends on the Linux distribution. On Ubuntu, for example, you can install the libxml2 debugging information with sudo apt-get install libxml2-dbg. See https://live.gnome.org/GettingTraces/DistroSpecificInstructions

    • 0