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

[Don Moir]

> On Mon, Dec 03, 2012 at 07:45:05AM -0500, Don Moir wrote:
>> If a crash or in case of abort happens to me then its ok. I test
>> ffmpeg quite a bit before I hand it out, but generally I will get
>> some kind of report from a beta tester that is not very clear and
>> from someone that does not know much program wise. We create a log
>> file for any kind of crash but right now it's kind of limited for
>> ffmpeg. I know the high level function where the crash occurred plus
>> registers plus unnamed assembler dump.
>
> For useful debugging I think you at least would need a back trace.
> Note that the raw program counters would be enough, you can get
> the line number data manually afterwards.
>
>> For a 'normal' crash not sure. For beta testing I could pass out debug dll's (I think).
>
> What would that help?
> I think debug dlls (assuming you mean built without optimizations) are
> a rather bad idea, it's much better to run the final code.
> However release build with full debug information can be very useful.
> You can still ship a stripped version as long as you have the version
> with debug info around to do the lookup.
> On linux at least it is even possible to split the debug info into
> a separate file.
> But the biggest issue is getting a proper stack trace. It's a big
> help if you can assume that debugging tools are installed,
> the code to automatically attach gdb or cdbg and have it print a
> stacktrace into some file is rather simple.

This is a windows app and no beta testers are going to have any linux / MinGW / Windows debugging tools.  The beta testers are not 
programmers.

Again for me if I get a crash its not a problem. Also generally not to much of a problem if I get a report of a crash but it can be.

The point about debug dlls for beta testing is to include named functions but not sure that would work. If it did work it doesn't do 
much good for shipping version.