[FFmpeg-devel] [PATCH] avcodec/alsdec: properly allocate raw_buffer

Thilo Borgmann thilo.borgmann at mail.de
Sun Jul 2 17:16:41 EEST 2017


Am 02.07.17 um 16:13 schrieb Paul B Mahol:
> On 7/2/17, Thilo Borgmann <thilo.borgmann at mail.de> wrote:
>> Am 01.07.17 um 03:38 schrieb Paul B Mahol:
>>> This also reverts 18f94df8.
>>>
>>> Fixes #5297.
>>>
>>> Signed-off-by: Paul B Mahol <onemda at gmail.com>
>>> ---
>>>  libavcodec/alsdec.c | 7 +------
>>>  1 file changed, 1 insertion(+), 6 deletions(-)
>>> [...]
>>> @@ -2062,7 +2057,7 @@ static av_cold int decode_init(AVCodecContext
>>> *avctx)
>>>      channel_size      = sconf->frame_length + sconf->max_order;
>>>
>>>      ctx->prev_raw_samples = av_malloc_array(sconf->max_order,
>>> sizeof(*ctx->prev_raw_samples));
>>> -    ctx->raw_buffer       = av_mallocz_array(avctx->channels *
>>> channel_size, sizeof(*ctx->raw_buffer));
>>> +    ctx->raw_buffer       = av_mallocz_array(avctx->channels *
>>> channel_size + sconf->max_order, sizeof(*ctx->raw_buffer));
>>>      ctx->raw_samples      = av_malloc_array(avctx->channels,
>>> sizeof(*ctx->raw_samples));
>>
>> This looks like guessing only about a needed overhead to the raw buffer.
>> What is
>> needed and actually done, is an overhead of max_order and that is already
>> added
>> to the buffer length three lines above the proposed change. So this is
>> nothing
>> more than guessing an overhead of 2*max_order should be enough but it does
>> not
>> resolve knowingly any cause of the bug.
>>
>> Therefore no, this still does not get applied until the actual reason of the
>> bug
>> is found and properly fixed. I've got less time than I thought today and I
>> could
>> not dive in as deep as I want. I cannot predict if there will be more time
>> for
>> me to do it soon. So Paul, I'd appreciate if you could solve this bug but I
>> will
>> only accept a proper patch and no guesswork.
> 
> This is not guesswork, The raw buffers needs this enough bytes.
> 
> See this line:
>     ctx->raw_samples[0] = ctx->raw_buffer + sconf->max_order;

No. The first max_order samples in the raw_buffer are used and the additional
size needed for them is already accounted for in calculation of channel_size
some lines above the allocation.
This leads to raw_samples[0][0] is max_order sample values after the beginning
of the buffer so that negative indices of raw_samples[0] work properly.

-Thilo


More information about the ffmpeg-devel mailing list