[Bug middle-end/28859] GCC calls malloc from within signal context

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28859

--- Comment #7 from Martin Liška  ---
Yep, let's forget about it ;)

[Bug middle-end/28859] GCC calls malloc from within signal context

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28859

--- Comment #6 from rguenther at suse dot de  ---
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  changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2017-07-17
>  Ever confirmed|0   |1
> 
> --- Comment #5 from Martin Liška  ---
> 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.

[Bug middle-end/28859] GCC calls malloc from within signal context

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28859

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-17
 Ever confirmed|0   |1

--- Comment #5 from Martin Liška  ---
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?

[Bug middle-end/28859] GCC calls malloc from within signal context

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28859

Richard Biener  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
*** Bug 81382 has been marked as a duplicate of this bug. ***

[Bug middle-end/28859] GCC calls malloc from within signal context

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28859

Richard Guenther  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #3 from Richard Guenther  2011-08-11 
09:58:48 UTC ---
*** Bug 50041 has been marked as a duplicate of this bug. ***

[Bug middle-end/28859] GCC calls malloc from within signal context

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2006-08-26 21:25 ---
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28859

[Bug middle-end/28859] GCC calls malloc from within signal context

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-08-26 21:18 ---
SIGABRT is not an async signal.  It is one of the few signal that is not.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28859