Quoting Luca Barbato (2016-04-18 12:56:26) > On 18/04/16 12:03, Hendrik Leppkes wrote: > > On Mon, Apr 18, 2016 at 12:00 PM, Luca Barbato <[email protected]> wrote: > >> On 18/04/16 10:47, Anton Khirnov wrote: > >>> Quoting Luca Barbato (2016-04-14 12:48:25) > >>>> On 14/04/16 12:21, wm4 wrote: > >>>>> From: Michael Niedermayer <[email protected]> > >>>>> > >>>>> Signed-off-by: Michael Niedermayer <[email protected]> > >>>>> --- > >>>>> libavcodec/mmaldec.c | 2 +- > >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>>>> > >>>>> diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c > >>>>> index a0685ea..5986658 100644 > >>>>> --- a/libavcodec/mmaldec.c > >>>>> +++ b/libavcodec/mmaldec.c > >>>>> @@ -166,7 +166,7 @@ static void ffmmal_stop_decoder(AVCodecContext > >>>>> *avctx) > >>>>> } > >>>>> ctx->waiting_buffers_tail = NULL; > >>>>> > >>>>> - assert(avpriv_atomic_get(&ctx->packets_buffered) == 0); > >>>>> + av_assert0(avpriv_atomic_get(&ctx->packets_buffered) == 0); > >>>>> > >>>>> ctx->frames_output = ctx->eos_received = ctx->eos_sent = > >>>>> ctx->packets_sent = ctx->extradata_sent = 0; > >>>>> } > >>>>> > >>>> > >>>> I'd rather not. > >>> > >>> Why not? > >>> > >> > >> For the same reason you do not link -lasan in release builds you'd > >> distribute. > >> > >> (and generally you do not crash on purpose when you are touching > >> hardware acceleration since that's the recipe for a reboot to cleanup > >> the kernel state if module unloading fails, never tried with mmal though) > >> > > > > The point of such an assertion is that when it would ever trigger, any > > further execution would be much worse than just bailing out here and > > now, because something crazy happened that would break everything > > either way. > > Sigh, WHY it would ever trigger would be the first question to answer, > secondary WHAT is the terrible doom if that would ever trigger. > > You must have something calling mmal_decode while at the same time you > are calling mmal_flush or mmal_close_decoder. > > Is that something you cannot prevent? Is that some behavior you would > expect?
That's the whole point of the assert -- it's something that should not be able to happen. If it does happen, then the code is buggy and the bug should be fixed. Another function of the assert (other than preventing UB) is that it tells you where exactly things went wrong, rather than crashing days later due to memory corruption. > > If you end up in that situation what happens? You leak packets? You > leave memory areas pinned in strange ways? You can root the system? You do something undefined. We should never ever do something undefined. Aborting is absolutely preferable to UB. -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
