Bug 28859 - GCC calls malloc from within signal context
Summary: GCC calls malloc from within signal context
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.1.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 50041 81382 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-08-26 21:09 UTC by Richard Biener
Modified: 2017-07-17 12:58 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2017-07-17 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Biener 2006-08-26 21:09:00 UTC
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.
Comment 1 Andrew Pinski 2006-08-26 21:18:27 UTC
SIGABRT is not an async signal.  It is one of the few signal that is not.
Comment 2 Richard Biener 2006-08-26 21:25:02 UTC
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.
Comment 3 Richard Biener 2011-08-11 09:58:48 UTC
*** Bug 50041 has been marked as a duplicate of this bug. ***
Comment 4 Richard Biener 2017-07-17 10:51:02 UTC
*** Bug 81382 has been marked as a duplicate of this bug. ***
Comment 5 Martin Liška 2017-07-17 12:48:32 UTC
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?
Comment 6 rguenther@suse.de 2017-07-17 12:57:03 UTC
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.
Comment 7 Martin Liška 2017-07-17 12:58:13 UTC
Yep, let's forget about it ;)