[MPlayer-users] Problem with uncleared buffers in "cue://" handler

[Ivan Kalvachev]

On 5/21/11, Linards Ticmanis <ticmanis at gmx.de> wrote:
> The function cue_find_bin() in stream/stream_cue.c fails to zero the
> buffers it uses, which leads to problems with previous memory content
> messing up the path that is being built. I propose this change to fix
> the problem:
>
>> --- stream/stream_cue.c (revision 33473)
>> +++ stream/stream_cue.c (working copy)
>> @@ -179,6 +179,10 @@
>>    char t[256];
>>    int fd_bin;
>>
>> +  memset(bin_filename, 0, sizeof bin_filename);
>> +  memset(s, 0, sizeof s);
>> +  memset(t, 0, sizeof t);
>> +
>>    /* get the filename out of that */
>>    /*                      12345 6  */
>>    mp_msg (MSGT_OPEN,MSGL_INFO, "[bincue] cue_find_bin(%s)\n", firstline);
>> (END)

It is recommended to send patches to mplayer-dev-eng maillist.
I guess you didn't consider your code to be real patch,
( sizeof() needs the brackets (/) :)

Anyway,
Would you test the attached patch?
I don't have cue/bin atm, so I'd like to hear if it fixes the issue you have.

I assume that in your case you were getting one additional random
character at the end of the bin_filename, the problem was [j+1].
I've added more checks, e.g. when "FILE:" is completely missing and
avoiding the bin_filename cases if so.

I'll commit it after I could test it myself too.


Best Regards.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cuebin.patch
Type: application/octet-stream
Size: 1034 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-users/attachments/20110529/f35ae591/attachment.obj>