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? 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? ... lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
