On Sat, Oct 24, 2015 at 3:26 PM, Ganesh Ajjanagadde <gajjanaga...@gmail.com> wrote: > On Sat, Oct 24, 2015 at 9:15 AM, Nicolas George <geo...@nsup.org> wrote: >> Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : >>> Fixes CID 1322329. >>> >>> Signed-off-by: Ganesh Ajjanagadde <gajjanaga...@gmail.com> >>> --- >>> libavcodec/pthread_frame.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c >>> index 7651211..ca06e3d 100644 >>> --- a/libavcodec/pthread_frame.c >>> +++ b/libavcodec/pthread_frame.c >>> @@ -305,7 +305,7 @@ static void release_delayed_buffers(PerThreadContext *p) >>> pthread_mutex_lock(&fctx->buffer_mutex); >>> >>> // fix extended data in case the caller screwed it up >>> - av_assert0(p->avctx->codec_type == AVMEDIA_TYPE_VIDEO || >> >>> + av_assert0(p->avctx && p->avctx->codec_type == AVMEDIA_TYPE_VIDEO >>> || >> >> I think the commit message should explain in what circumstances p->avctx can >> be NULL. Otherwise, the extra test is only hiding a problem earlier in the >> code. > > Ok, will check in more detail. Thanks. >
More the the point, if this actually can be NULL, then an assert is not what should check that, since asserts are just like crashes (even if safer from a security point) If it can't be NULL, then it seems like a false positive. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
