Hello,
In the past while I have been rounding up development for a streaming server for the radio station I am part of. However, during the last stress testing phase I noticed that memory usage slowly increases as streaming clients disconnect and connect. At first I was convinced it was some leak in my own code but valgrind didn't confirm that this was happening. However, I noticed that there was quite some lost memory originating in the mad_layer_III() function in layer3.c:
==5957== 7,701 bytes in 3 blocks are definitely lost in loss record 68 of 85 ==5957== at 0x481B72C: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==5957== by 0x485F1C1: mad_layer_III (in /usr/lib/libmad.so.0.2.1) ==5957== by 0x485429A: mad_frame_decode (in /usr/lib/libmad.so.0.2.1) ==5957== by 0x7775: decode_data (server.c:318) ==5957== by 0x9387: server (server.c:980) ==5957== by 0x4874164: pthread_start_thread (in /lib/libpthread-0.10.so) ==5957== by 0x4A176E9: clone (in /lib/libc-2.3.6.so)
==5957== 13,824 bytes in 3 blocks are definitely lost in loss record 71 of 85 ==5957== at 0x481CE9E: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==5957== by 0x485F215: mad_layer_III (in /usr/lib/libmad.so.0.2.1) ==5957== by 0x485429A: mad_frame_decode (in /usr/lib/libmad.so.0.2.1) ==5957== by 0x7775: decode_data (server.c:318) ==5957== by 0x9387: server (server.c:980) ==5957== by 0x4874164: pthread_start_thread (in /lib/libpthread-0.10.so) ==5957== by 0x4A176E9: clone (in /lib/libc-2.3.6.so)
One would assume this is just caused by memory not being free()'d up when the program exits, but the longer the server has run, the more memory was definitely lost, indicating that the memory loss originates here.
I use the mad library in such a way that I manually line up data and decode this data per frame, which is required to ensure certain functionality of the streaming server. I made sure that when I reinitialize the decoder every time I run the mad_*_finish() operations on all the structs I use before running mad_*_init() again. However, I suspect that not all allocated memory is freed as it should.
Am I missing something or could it be that using mad this way hasn't been tested excessively enough and is it true that the memory alllocated in mad_layer_III() on lines 2530 and 2538 (libmad version 0.15.1b) is not freed properly? I would be delighted to either get confirmation on this or some advice on how to solve this issue. If more information is required I will do my best to provide this.
Regards,
Niels Roosen