[FFmpeg-devel] segfault in af_afade.c::activate

Paul B Mahol onemda at gmail.com
Wed Oct 16 02:03:39 EEST 2019


Should be fixed.

On 10/16/19, Mark Niebur <mniebur at thuuz.com> wrote:
> I'm sorry for not specifying.  In the case that data is not ready from
> ctx->inputs[1] after crossfade is over, ff_inlink_consume_frame will return
> 0 and not set the frame pointer.  If ff_outlink_frame_wanted is still 0, the
> function will fall through to the code filtering the frame, although the
> frame pointer is NULL.  This is the affected code in af_afade.c:
>
> 455     if (s->crossfade_is_over) {
> 456         ret = ff_inlink_consume_frame(ctx->inputs[1], &in);
> 457         if (ret < 0) {
> 458             return ret;
> 459         } else if (ff_inlink_acknowledge_status(ctx->inputs[1], &status,
> &pts)) {
> 460             ff_outlink_set_status(ctx->outputs[0], status, pts);
> 461             return 0;
> 462         } else {
> 463             if (ff_outlink_frame_wanted(ctx->outputs[0]) && !in) {
> 464                 ff_inlink_request_frame(ctx->inputs[1]);
> 465                 return 0;
> 466             }
> 467         }
> 468         in->pts = s->pts;
> 469         s->pts += av_rescale_q(in->nb_samples,
> 470             (AVRational){ 1, outlink->sample_rate },
> outlink->time_base);
> 471         return ff_filter_frame(outlink, in);
> 472     }
>
>> On Oct 15, 2019, at 4:29 PM, Paul B Mahol <onemda at gmail.com> wrote:
>>
>> On 10/15/19, Mark Niebur <mniebur at thuuz.com <mailto:mniebur at thuuz.com>>
>> wrote:
>>> I just checked out master and I see the fix you mentioned.  This does not
>>> completely fix acrossfade for me.  I also had to apply the following
>>> patch:
>>
>> What this patch fixes?
>>
>>> diff --git a/libavfilter/af_afade.c b/libavfilter/af_afade.c
>>> index 195fb65..446aa0a 100644
>>> --- a/libavfilter/af_afade.c
>>> +++ b/libavfilter/af_afade.c
>>> @@ -459,11 +459,11 @@ static int activate(AVFilterContext *ctx)
>>>         } else if (ff_inlink_acknowledge_status(ctx->inputs[1], &status,
>>> &pts)) {
>>>             ff_outlink_set_status(ctx->outputs[0], status, pts);
>>>             return 0;
>>> -        } else {
>>> -            if (ff_outlink_frame_wanted(ctx->outputs[0]) && !in) {
>>> +        } else if (!in) {
>>> +            if (ff_outlink_frame_wanted(ctx->outputs[0])) {
>>>                 ff_inlink_request_frame(ctx->inputs[1]);
>>> -                return 0;
>>>             }
>>> +           return 0;
>>>         }
>>>         in->pts = s->pts;
>>>         s->pts += av_rescale_q(in->nb_samples,
>>>
>>> Thanks,
>>> Mark
>>>
>>>> On Oct 15, 2019, at 2:26 PM, Paul B Mahol <onemda at gmail.com> wrote:
>>>>
>>>> On 10/15/19, Mark Niebur <mniebur at thuuz.com> wrote:
>>>>> Hello,
>>>>> I'm trying to debug an issue I'm seeing where the filter "acrossfade"
>>>>> produces a segfault.  This seemingly only happens in docker containers,
>>>>> and
>>>>> I am seeing it when running a rather large filter chain.  I'm trying to
>>>>> get
>>>>> to the bottom of it, but it would be really helpful to understand the
>>>>> context around how libavfilter fills the filter input fifos.  This is
>>>>> the
>>>>> code where I'm seeing the segfault:
>>>>> 449     AVFrame *in = NULL, *out, *cf[2] = { NULL };
>>>>> ...
>>>>> 474     if (ff_inlink_queued_samples(ctx->inputs[0]) > s->nb_samples) {
>>>>> 475         // consume some samples - this is not a crossfade overlap
>>>>> 486     } else if (ff_inlink_queued_samples(ctx->inputs[1]) >=
>>>>> s->nb_samples) {
>>>>> 487         if (s->overlap) {
>>>>> 488             out = ff_get_audio_buffer(outlink, s->nb_samples);
>>>>> 489             if (!out)
>>>>> 490                 return AVERROR(ENOMEM);
>>>>> 491             // NO CHECK IS DONE HERE THAT ENOUGH SAMPLES ARE
>>>>> PRESENT
>>>>> 491             // In our case, there are 0 samples, so
>>>>> ff_inlink_consume_samples returns early and does not set cf[0]
>>>>> 492             ret = ff_inlink_consume_samples(ctx->inputs[0],
>>>>> s->nb_samples, s->nb_samples, &cf[0]);
>>>>> 493             if (ret < 0) {
>>>>> 494                 av_frame_free(&out);
>>>>> 495                 return ret;
>>>>> 496             }
>>>>> 497             // SEGFAULT HERE
>>>>> 498             ret = ff_inlink_consume_samples(ctx->inputs[1],
>>>>> s->nb_samples, s->nb_samples, &cf[1]);
>>>>> 499             if (ret < 0) {
>>>>> 500                 av_frame_free(&out);
>>>>> 501                 return ret;
>>>>> 502             }
>>>>>
>>>>> How does avfilter add samples to an inlink?  Does it just fill it
>>>>> randomly
>>>>> or will it fill input 0 completely and then move on to input 1, 2, 3?
>>>>> Even
>>>>> when I fix this segfault by ensuring that
>>>>> ff_inlink_queued_samples(ctx->inputs[0]) == s->nb_samples, I will still
>>>>> get
>>>>> additional segfaults in the acrossfade code where
>>>>> ff_inlink_consume_samples
>>>>> returns 0 and does not set the frame pointer.
>>>>
>>>> I think this was just reported and fixed very recently.
>>>>
>>>>> _______________________________________________
>>>>> ffmpeg-devel mailing list
>>>>> ffmpeg-devel at ffmpeg.org
>>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>>>
>>>>> To unsubscribe, visit link above, or email
>>>>> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>>>> _______________________________________________
>>>> ffmpeg-devel mailing list
>>>> ffmpeg-devel at ffmpeg.org
>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>>
>>>> To unsubscribe, visit link above, or email
>>>> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>>>
>>> _______________________________________________
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel at ffmpeg.org <mailto:ffmpeg-devel at ffmpeg.org>
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>> <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>
>>>
>>> To unsubscribe, visit link above, or email
>>> ffmpeg-devel-request at ffmpeg.org <mailto:ffmpeg-devel-request at ffmpeg.org>
>>> with subject "unsubscribe".
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org <mailto:ffmpeg-devel at ffmpeg.org>
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-request at ffmpeg.org <mailto:ffmpeg-devel-request at ffmpeg.org>
>> with subject "unsubscribe".
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".


More information about the ffmpeg-devel mailing list