> abort() should generally not be in a reachable part of the code - not inside > any of the libraries anyway, ffmpeg.c is a different topic. > If it is reachable with any input files, and not just present to shut up > compilers, this is a bug and should be addressed to return an error instead. > > Therefore, we should address those cases, and just leave abort as-is > otherwise. Nevermind that av_abort would need to be a public function, which > sounds like a really bad idea. > > - Hendrik
Historically, we had issues with the abort() within libavcodec/vlc.c alloc_table(), but possibly those are now fixed. > A program that terminates on abort() does leave a core dump, I just checked. > > Nicolas George We had a different behavior on Windows back then. Now that we can compile ffmpeg with VisualStudio (instead of cross-compiling with gcc on Linux), we will try to re-go the route of SIGABRT signal handler, and see if we got more success now that we have the same C runtime. (We had a custom handler to create a "full mini-dump" with dbghelp.dll) Thanks to make me realize our problem (and solution) is now potentially obsolete. Julien _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
