[FFmpeg-devel] [PATCH 3/3] Add assert that the avcodec lock isheld when initializing static VLC tables.

[Don Moir]

> On Sun, Dec 02, 2012 at 05:35:33PM -0500, Don Moir wrote:
>> Looks to me there are hundreds of places av_assert0 is called and
>> not just a few and av_assert0 calls abort. The thing is I would like
>> to have an easy indication where and why it failed. This is simple
>> enough for you isn't it ?
>
> As Nicolas pointed out, the why is completely unknown (otherwise we
> probably should indeed not be using an assert).
> We do not have a context around either most of the time I'm afraid.
>
>> If appropriate it could be ff_abort (AVFormatContext,reason); or
>> whatever. ff_abort is set by app. With your aborts you have the
>> opportunity to give it back to the app in a cleaner way if you
>> choose.
>
> While that shouldn't be a big issue, what would you then do
> after your callback is being called?
> Without context and reason being available you won't really have
> anything more than you'd get in a signal handler...
>
>> We actually already have a handler in place but its not convienent
>> for tracking the actual cause of the problem somewhere in ffmpeg and
>> by allowing a settable abort call this would help to isolate the
>> problem.
>
> If by "handler" you mean signal handler, I'd think the obvious question
> would be: why not improve that signal handler so it can provide you
> all the information you need?
> Obviously not as easy as it sounds, but at least a backtrace should
> be possible and is definitely a very good start.

Yep could do this but essentially the trace is going to be some high level ffmpeg call (we already know that) with probably quite a 
bit of depth of assembler. So then I can hunt it down in my leasure time :) picking thru trying to find the problem when the exact 
location could have been passed to me and then I could inform the user we are shutting down after creating a log report that would 
be useful.

The app contains the exact ffmpeg build string as well.