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
Jussi Kukkonen
2009-Dec-08 11:36 UTC
[Icecast-dev] Memory leak on Icecast 2.3.2 / Debian ?
Gilles PIETRI wrote:> 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:...> 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!xmlEncodeEntitiesReentrant() return values must be freed, so probably not a libxml problem. The Debian Testing Icecast source (2.3.2-4) does seem to have a case where they are not freed: a do-while loop in stats.c:stats_get_xml() can leak when breaking early. This code is not present in -kh17 that I'm using and all xmlEncodeEntitiesReentrant() calls are fine there. - Jussi
Romain Beauxis
2009-Dec-08 16:08 UTC
[Icecast-dev] Memory leak on Icecast 2.3.2 / Debian ?
Hi all ! Le mardi 8 d?cembre 2009 05:36:53, Jussi Kukkonen a ?crit :> > 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! > > xmlEncodeEntitiesReentrant() return values must be freed, so probably > not a libxml problem. > > The Debian Testing Icecast source (2.3.2-4) does seem to have a case > where they are not freed: a do-while loop in stats.c:stats_get_xml() can > leak when breaking early. This code is not present in -kh17 that I'm > using and all xmlEncodeEntitiesReentrant() calls are fine there.I'm co-maintaining the Debian package. I have no time to test it myself right now, but I'd be interested to have your feedback and fix the issue if you find it. Romain