[Icecast-dev] Memory leak on Icecast 2.3.2 / Debian ?

[Gilles PIETRI]

Hi,

I've been noticing a huge memory usage on Icecast 2.3.2 on multiple 
debian instances. They are using like 100 MB after a day and going on 
until they hit like 1 GB.. So I ran one in valgrind, and killed it after 
~24h, here is the output:

==30481== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 38 from 3)
==30481== malloc/free: in use at exit: 44,448,584 bytes in 44,470 blocks.
==30481== malloc/free: 16,416,062 allocs, 16,371,592 frees, 
6,722,622,089 bytes allocated.
==30481== For counts of detected errors, rerun with: -v
==30481== searching for pointers to 44,470 not-freed blocks.
==30481== checked 468,248 bytes.
==30481==
==30481== 584 (104 direct, 480 indirect) bytes in 2 blocks are 
definitely lost in loss record 1 of 5
==30481==    at 0x4C2260E: malloc (vg_replace_malloc.c:207)
==30481==    by 0x618152F: (within /lib/libc-2.7.so)
==30481==    by 0x6181D06: __nss_database_lookup (in /lib/libc-2.7.so)
==30481==    by 0x918C31F: ???
==30481==    by 0x918D3D6: ???
==30481==    by 0x613FEA2: getpwnam_r (in /lib/libc-2.7.so)
==30481==    by 0x613F85F: getpwnam (in /lib/libc-2.7.so)
==30481==    by 0x4079FE: (within /usr/bin/icecast2)
==30481==    by 0x60C11A5: (below main) (in /lib/libc-2.7.so)
==30481==
==30481==
==30481== 3,000 bytes in 3 blocks are possibly lost in loss record 4 of 5
==30481==    at 0x4C2260E: malloc (vg_replace_malloc.c:207)
==30481==    by 0x5B5A007: xmlEncodeEntitiesReentrant (in 
/usr/lib/libxml2.so.2.6.32)
==30481==    by 0x40FB10: (within /usr/bin/icecast2)
==30481==    by 0x40FC01: (within /usr/bin/icecast2)
==30481==    by 0x41911C: (within /usr/bin/icecast2)
==30481==    by 0x41946D: (within /usr/bin/icecast2)
==30481==    by 0x40A5C1: (within /usr/bin/icecast2)
==30481==    by 0x42007C: (within /usr/bin/icecast2)
==30481==    by 0x5E8DFC6: start_thread (in /lib/libpthread-2.7.so)
==30481==    by 0x61725AC: clone (in /lib/libc-2.7.so)
==30481==
==30481==
==30481== 44,445,000 bytes in 44,445 blocks are definitely lost in loss 
record 5 of 5
==30481==    at 0x4C2260E: malloc (vg_replace_malloc.c:207)
==30481==    by 0x5B5A007: xmlEncodeEntitiesReentrant (in 
/usr/lib/libxml2.so.2.6.32)
==30481==    by 0x40FB10: (within /usr/bin/icecast2)
==30481==    by 0x40FC01: (within /usr/bin/icecast2)
==30481==    by 0x41911C: (within /usr/bin/icecast2)
==30481==    by 0x41946D: (within /usr/bin/icecast2)
==30481==    by 0x40A5C1: (within /usr/bin/icecast2)
==30481==    by 0x42007C: (within /usr/bin/icecast2)
==30481==    by 0x5E8DFC6: start_thread (in /lib/libpthread-2.7.so)
==30481==    by 0x61725AC: clone (in /lib/libc-2.7.so)
==30481==
==30481== LEAK SUMMARY:
==30481==    definitely lost: 44,445,104 bytes in 44,447 blocks.
==30481==    indirectly lost: 480 bytes in 20 blocks.
==30481==      possibly lost: 3,000 bytes in 3 blocks.
==30481==    still reachable: 0 bytes in 0 blocks.
==30481==         suppressed: 0 bytes in 0 blocks.

Funnily enough, I've been running one (almost forgotten) instance of 
Icecast 2.3.2-kh4 since september on a similar configuration, compiled 
from source, and I don't have this problem.

The valgrind output seems to indicate a leak in libxml2, I'm gonna try 
to see if this is linked to the way the icecast or libxml package is 
compiled/patched in debian, but I'm not too familiar with this kind of 
problems, so if you have something to say about this issue, I'd love to 
hear about it!

Regards,
Gilou