If running gcc with glibc malloc checking turned on (MALLOC_CHECK_=2), on heap corruption the SIGABRT raised by glibc will cause gcc to deadlock because it calls async-singal-unsafe malloc () from the signal context to do the diagnostic.
SIGABRT is not an async signal. It is one of the few signal that is not.
http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html " All functions not in the above table are considered to be unsafe with respect to signals. In the presence of signals, all functions defined by this volume of IEEE Std 1003.1-2001 shall behave as defined when called from or interrupted by a signal-catching function, with a single exception: when a signal interrupts an unsafe function and the signal-catching function calls an unsafe function, the behavior is undefined." malloc is not included in this list. Now, it is unfortunate that glibc raises SIGABRT from inside malloc.
*** Bug 50041 has been marked as a duplicate of this bug. ***
*** Bug 81382 has been marked as a duplicate of this bug. ***
Do I understand it that practically impossible to handle that as we would have to somehow detect all malloc-family functions triggered after a crash_signal is executed? In case of PR81382 we either need to have layout class not containing of types that can possibly allocate a memory via malloc, or we can have an env variable that will prevent displaying of locations if crash_signal happened? Would it be welcomed one of there approaches?
On Mon, 17 Jul 2017, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28859 > > Martin Liška <marxin at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |NEW > Last reconfirmed| |2017-07-17 > Ever confirmed|0 |1 > > --- Comment #5 from Martin Liška <marxin at gcc dot gnu.org> --- > Do I understand it that practically impossible to handle that as we would have > to somehow detect all malloc-family functions triggered after a crash_signal is > executed? > > In case of PR81382 we either need to have layout class not containing of types > that can possibly allocate a memory via malloc, or we can have an env variable > that will prevent displaying of locations if crash_signal happened? Would it be > welcomed one of there approaches? I think it's just not possible to easily do sth here, so we shouldn't care too much IMHO.
Yep, let's forget about it ;)