[ 
http://dev.sourcefabric.org/browse/LS-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Samuel Mimram resolved LS-647.
------------------------------

    Resolution: Fixed

Hi,

I'm glad you reported this this allowed me to spot two bugs in the mp4 decoder:
1. There was a small memory leak (2 bytes) each time we initialized the decoder 
(fixed in a33f936f7fc634b8a49ad2d46e0dceff79437460).
2. In some situations, as yours, we were trying to decode past the end of the 
mp4 track causing us to read in random memory, and thus allocating random 
amounts of memory (fixed in 8a1b6bbdf623ba2139ecdad45a72ccb245e5d351).

You can find those fixes in the current git repository, or wait for the next 
release!

> 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
>         Attachments: valgrind.log, valgrind2.log
>
>
> 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 Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
_______________________________________________
Savonet-devl mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-devl

Répondre à