Hello, I noticed av_asser0 macro is extensively used in ffmpeg code... simple grep returns some 11xx hits. Inside this macro abort() call is used. Two questions in my mind: 1. why abort() and not exit() with a err code (i.e. EXIT_FAILURE) 2, if we trigger abort purposely, why not have a signal handler for it and do proper flushing cleanup upon exception detection? Seems SIGABRT (a POSIX signal) does not currently have any handler in ffmpeg. I am sure there are reasons, I am just eager to find reasons behind this... Thank you, Mircea
Am 27.02.2020 um 09:35 schrieb Mircea Carausu via ffmpeg-user <ffmpeg-user@ffmpeg.org>:
I noticed av_asser0 macro is extensively used in ffmpeg code... simple grep returns some 11xx hits. Inside this macro abort() call is used. Two questions in my mind: 1. why abort() and not exit() with a err code (i.e. EXIT_FAILURE) 2, if we trigger abort purposely, why not have a signal handler for it and do proper flushing cleanup upon exception detection? Seems SIGABRT (a POSIX signal) does not currently have any handler in ffmpeg.
The abort() calls are not supposed to actually be hit. If you want to catch them in your code using the libraries, you should do so. Carl Eugen
Carl Eugen Hoyos (12020-02-27):
The abort() calls are not supposed to actually be hit. If you want to catch them in your code using the libraries, you should do so.
But if the abort() are reached, that's a bug, either in FFmpeg or in the program that uses its libraries. Catching the signal is likely to make things worse. Remember that these asserts may be the final barrier against an exploitable bug. The proper way of dealing with assert failure is to fix them. Regards, -- Nicolas George
Le 27/02/2020 19:35:24, Nicolas George a écrit :
Carl Eugen Hoyos (12020-02-27):
The abort() calls are not supposed to actually be hit. If you want to catch them in your code using the libraries, you should do so.
But if the abort() are reached, that's a bug, either in FFmpeg or in the program that uses its libraries. Catching the signal is likely to make things worse. Remember that these asserts may be the final barrier against an exploitable bug.
And in case of a catastophic event, with abort() you can have a coredump for postmortem analysing... -- -------( https://framasphere.org/tags/tetalab )-------------------------
Many thanks for all replies. It provides the background info I was looking for. Thank you, Mircea On Thu, Feb 27, 2020 at 11:17 AM tth <sigfood@dinorama.fr> wrote:
Le 27/02/2020 19:35:24, Nicolas George a écrit :
Carl Eugen Hoyos (12020-02-27):
The abort() calls are not supposed to actually be hit. If you want to catch them in your code using the libraries, you should do so.
But if the abort() are reached, that's a bug, either in FFmpeg or in the program that uses its libraries. Catching the signal is likely to make things worse. Remember that these asserts may be the final barrier against an exploitable bug.
And in case of a catastophic event, with abort() you can have a coredump for postmortem analysing...
-- -------( https://framasphere.org/tags/tetalab )------------------------- _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
Am 27.02.2020 um 09:35 schrieb Mircea Carausu via ffmpeg-user <ffmpeg-user@ffmpeg.org>:
why abort() and not exit() with a err code (i.e. EXIT_FAILURE)
The proper answer here is that libraries are not supposed to call exit(). Carl Eugen
participants (4)
-
Carl Eugen Hoyos -
Mircea Carausu -
Nicolas George -
tth