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

Mark Niebur mniebur at thuuz.com
Wed Oct 16 02:06:45 EEST 2019


This should be fixed already on master?  I checked a few hours ago and was
able to repro.

On Tue, Oct 15, 2019, 5:03 PM Paul B Mahol <onemda at gmail.com> wrote:

> 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".
> _______________________________________________
> 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