Memory leak in AAC decoder
--------------------------
Key: LS-647
URL: http://dev.sourcefabric.org/browse/LS-647
Project: Liquidsoap
Issue Type: Bug
Components: Liquidsoap
Affects Versions: 1.0, 1.0.0+dev
Environment: Ubuntu 12.04 LTS
Reporter: Torben Weibert
Priority: Major
We are currently evaluating Liquidsoap for an online radio streaming service.
Our music library is based on an iTunes library, and all files are in AAC
(iTunes m4a) format.
We found that after playing a few songs, liquidsoap will suddenly eat up
massive amounts of memory (usually around 2.5 GB) and eventually stop playing.
Apparently it always happens when liquidsoap switches to a new song. Sometimes
after the first song, sometimes only after an hour or so. The process doesn't
crash but just sits there and does nothing.
1159 tw 20 0 7522m 2.6g 5800 S 2 68.5 0:14.96 liquidsoap
In the log file, I see a "catchup" message like this:
2013/01/15 10:50:59 [test(dot)m4a:3] Prepared "test.m4a" (RID 0).
2013/01/15 10:54:13 [clock.wallclock_main:2] We must catchup 2.35 seconds!
The problem can be reproduced with this simple one-liner:
output.dummy(mksafe(single("test.m4a")))
This is on both the v1.0.0 included with Ubuntu 12.04 as well as the latest dev
version from hg. When I use MP3 files instead, everything works fine. So the
problem must be related to the AAC decoder.
I have subsequently tried to track down the source of the issue using valgrind,
and in fact, it reports a leaked block of > 2 GB size inside the code of
ocaml_faad:
==28736== 2,214,429,630 bytes in 1 blocks are possibly lost in loss record 223
of 223
==28736== at 0x4C2B6CD: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28736== by 0x6B066E: mp4ff_read_sample (mp4ff.c:427)
==28736== by 0x6AF91C: ocaml_faad_mp4_decode (faad_stubs.c:550)
==28736== by 0x6E8DD3: ??? (in /usr/local/bin/liquidsoap)
==28736== by 0xA090: ???
==28736== by 0xA0F7D6F: ???
==28736== by 0xA0F80F7: ???
==28736== by 0x5B938B: camlDecoder__fill_1221 (in /usr/local/bin/liquidsoap)
==28736== by 0xD44FA9F: ???
==28736== by 0x5B92B3: camlDecoder__fill_1221 (in /usr/local/bin/liquidsoap)
==28736== by 0x960877F: ???
==28736== by 0xA0F7E4F: ???
Line 427 of mp4ff.c is the malloc call inside mp4ff_read_sample:
int32_t mp4ff_read_sample(mp4ff_t *f, const int32_t track, const int32_t sample,
uint8_t **audio_buffer, uint32_t *bytes)
{
int32_t result = 0;
*bytes = mp4ff_audio_frame_size(f, track, sample);
if (*bytes==0) return 0;
*audio_buffer = (uint8_t*)malloc(*bytes); // line 427
...
}
So I believe there must be something wrong about the return value of
mp4ff_audio_frame_size so that an insanely huge block of memory is allocated.
Also, there must be a condition that causes that block to not being freed again.
I have looked at the code from faad_stubs.c where mp4ff_read_sample is called,
but I can't see any obvious mistakes. We would really appreciate any help from
the developers here.
Thank you
Torben
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://dev.sourcefabric.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
Savonet-devl mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-devl
