[Bug ada/64478] New: Ada Exception handlers call signal-unsafe malloc/free

[Bug ada/64478] New: Ada Exception handlers call signal-unsafe malloc/free

[bernd.edlinger at hotmail dot de]

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

            Bug ID: 64478
           Summary: Ada Exception handlers call signal-unsafe malloc/free
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ada
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bernd.edlinger at hotmail dot de

for instance c52104x:
gdb ./c52104x
b s-memory.adb:92
r
Starting program: /home/ed/gnu/gcc-test/c52104x 

,.,. C52104X ACATS 2.5 15-01-03 04:40:03
---- C52104X CHECK THAT IN ARRAY ASSIGNMENTS AND IN SLICE ASSIGNMENTS,
                THE LENGTHS MUST MATCH; ALSO CHECK WHETHER
                CONSTRAINT_ERROR OR STORAGE_ERROR ARE RAISED FOR LARGE
                ARRAYS.
   - C52104X NO CONSTRAINT_ERROR FOR TYPE WITH 'LENGTH = INTEGER'LAST + 
                3.

Program received signal SIGSEGV, Segmentation fault.
c52104x () at c52104x.adb:113
113                                 (IDENT_INT(-2)..IDENT_INT( INTEGER'LAST));
(gdb) c
Continuing.

Breakpoint 1, <__gnat_malloc> (size=size@entry=704) at s-memory.adb:92
92             Result := c_malloc (System.CRTL.size_t (Actual_Size));
(gdb) bt
#0  <__gnat_malloc> (size=size@entry=704) at s-memory.adb:92
#1  0x000000000041ab30 in system.exceptions.machine.new_occurrence () at
s-excmac.ads:183
#2  0x0000000000407603 in
ada.exceptions.exception_propagation.allocate_occurrence () at a-exexpr.adb:188
#3  0x0000000000408475 in ada.exceptions.create_occurrence_from_signal_handler
(e=0x633b60 <storage_error>, m=(system.address) 0x426710) at a-except.adb:1058
#4  0x00000000004084c2 in ada.exceptions.raise_from_signal_handler
(e=<optimized out>, m=<optimized out>) at a-except.adb:1093
#5  <signal handler called>
#6  c52104x () at c52104x.adb:113
(gdb)

[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free

[bernd.edlinger at hotmail dot de]

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

--- Comment #1 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
I found this initially with TSAN:

RUN c52104x
^M
,.,. C52104X ACATS 2.5 15-01-03 04:12:21^M
---- C52104X CHECK THAT IN ARRAY ASSIGNMENTS AND IN SLICE ASSIGNMENTS,^M
                THE LENGTHS MUST MATCH; ALSO CHECK WHETHER^M
                CONSTRAINT_ERROR OR STORAGE_ERROR ARE RAISED FOR LARGE^M
                ARRAYS.^M
   - C52104X NO CONSTRAINT_ERROR FOR TYPE WITH 'LENGTH = INTEGER'LAST + ^M
                3.^M
==================^M
^[[1m^[[31mWARNING: ThreadSanitizer: signal-unsafe call inside of a signal
(pid=9681)^M
^[[1m^[[0m    #0 malloc
../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors.cc:491
(libtsan.so.0+0x000000025c33)^M
    #1 __gnat_malloc /home/ed/gnu/gcc-build/gcc/ada/rts/s-memory.adb:92
(c52104x+0x000000407070)^M
    #2 main <null> (c52104x+0x000000402f93)^M
^M
SUMMARY: ThreadSanitizer: signal-unsafe call inside of a signal
/home/ed/gnu/gcc-build/gcc/ada/rts/s-memory.adb:92 __gnat_malloc^M
==================^M
   - C52104X STORAGE_ERROR RAISED WHEN DECLARING TWO PACKED BOOLEAN^M
                ARRAYS WITH INTEGER'LAST + 3 COMPONENTS.^M
==================^M
^[[1m^[[31mWARNING: ThreadSanitizer: signal-unsafe call inside of a signal
(pid=9681)^M
^[[1m^[[0m    #0 free
../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors.cc:538
(libtsan.so.0+0x000000025f29)^M
    #1 __gnat_free /home/ed/gnu/gcc-build/gcc/ada/rts/s-memory.adb:113
(c52104x+0x0000004070c1)^M
    #2 main <null> (c52104x+0x000000402f93)^M
^M
SUMMARY: ThreadSanitizer: signal-unsafe call inside of a signal
/home/ed/gnu/gcc-build/gcc/ada/rts/s-memory.adb:113 __gnat_free^M
==================^M
==== C52104X PASSED ============================.^M
ThreadSanitizer: reported 2 warnings^M
PASS:   c52104x

[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think in this case tsan is incorrect, as the signal handler never returns. 
This is how C++ exceptions work with non-call signals also.

[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger <bernd.edlinger at hotmail dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #3 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Andrew Pinski from comment #2)
> I think in this case tsan is incorrect, as the signal handler never returns.
> This is how C++ exceptions work with non-call signals also.

I dont think so.

Because the exception could happen also because of stack overflow
or simply asynchronos.

for instance ga stack overflow in malloc.
or a kill -SIGILL while executing malloc.

that will deadlock then in the signal handler.

[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Then all use of exceptions inside signal handling is broken including and not
limited to JDK's use of it and GCJ use too.

[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free

[bernd.edlinger at hotmail dot de]

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

--- Comment #5 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
but I cant see why a potential deadlock in an exception
handler is not a bug?

[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Bernd Edlinger from comment #5)
> but I cant see why a potential deadlock in an exception
> handler is not a bug?

Actually here is what glibc says about malloc:
Function: void * malloc (size_t size)
Preliminary: | MT-Safe | AS-Unsafe lock | AC-Unsafe lock fd mem | See POSIX
Safety Concepts.

But this is a non-Async-Signal here we are talking about so this is safe and a
bug in tsan for not realizing that.

[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger <bernd.edlinger at hotmail dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #7 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Andrew Pinski from comment #6)
> Actually here is what glibc says about malloc:
> Function: void * malloc (size_t size)
> Preliminary: | MT-Safe | AS-Unsafe lock | AC-Unsafe lock fd mem | See POSIX
> Safety Concepts.
> 
> But this is a non-Async-Signal here we are talking about so this is safe and
> a bug in tsan for not realizing that.

Well, in this example the signal is synchonous,
but I see the same problem also when the stack overflows.

Ada installs a separate signal handler stack. So it is supposed to handle
that signal and do something about it, for instance re-boot the system or
something really security relevant.

That will not happen if the stack overflows inside malloc.

For instance this test case:

ulimit -s 1000
./c380004

,.,. C380004 ACATS 2.5 15-01-03 09:13:13
---- C380004 Check evaluation of discriminant expressions when the
                constraint depends on a discriminant, and the
                discriminants have defaults -
                discriminant-dependententry families and protected
                components.
   - C380004 Discriminant-dependent entry families for task types.
   - C380004 Discriminant-dependent entry families for protected types.
==================
WARNING: ThreadSanitizer: signal-unsafe call inside of a signal (pid=19947)
    #0 malloc ../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors.cc:491
(libtsan.so.0+0x000000025c33)
    #1 __gnat_malloc /home/ed/gnu/gcc-build/gcc/ada/rts/s-memory.adb:92
(c380004+0x0000004330c0)
    #2 _ada_c380004 /home/ed/gnu/gcc-test/c380004.adb:341
(c380004+0x000000406700)
    #3 main /home/ed/gnu/gcc-test/b~c380004.adb:301 (c380004+0x0000004040be)

SUMMARY: ThreadSanitizer: signal-unsafe call inside of a signal
/home/ed/gnu/gcc-build/gcc/ada/rts/s-memory.adb:92 __gnat_malloc
==================
==================
WARNING: ThreadSanitizer: signal-unsafe call inside of a signal (pid=19947)
    #0 malloc ../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors.cc:491
(libtsan.so.0+0x000000025c33)
    #1 __gnat_malloc /home/ed/gnu/gcc-build/gcc/ada/rts/s-memory.adb:92
(c380004+0x0000004330c0)
    #2 _ada_c380004 /home/ed/gnu/gcc-test/c380004.adb:341
(c380004+0x000000406700)
    #3 main /home/ed/gnu/gcc-test/b~c380004.adb:301 (c380004+0x0000004040be)

SUMMARY: ThreadSanitizer: signal-unsafe call inside of a signal
/home/ed/gnu/gcc-build/gcc/ada/rts/s-memory.adb:92 __gnat_malloc
==================
   * C380004 Unexpected exception.
**** C380004 FAILED ****************************.
==================
WARNING: ThreadSanitizer: signal-unsafe call inside of a signal (pid=19947)
    #0 free ../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors.cc:538
(libtsan.so.0+0x000000025f29)
    #1 __gnat_free /home/ed/gnu/gcc-build/gcc/ada/rts/s-memory.adb:113
(c380004+0x000000433111)
    #2 _ada_c380004 /home/ed/gnu/gcc-test/c380004.adb:341
(c380004+0x000000406700)
    #3 main /home/ed/gnu/gcc-test/b~c380004.adb:301 (c380004+0x0000004040be)

SUMMARY: ThreadSanitizer: signal-unsafe call inside of a signal
/home/ed/gnu/gcc-build/gcc/ada/rts/s-memory.adb:113 __gnat_free
==================
ThreadSanitizer: reported 3 warnings


see: the signal handler calls malloc and free, and apparently
evenreturns and prints "* C380004 Unexpected exception."

[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Bernd Edlinger from comment #7)
> (In reply to Andrew Pinski from comment #6)
> > Actually here is what glibc says about malloc:
> > Function: void * malloc (size_t size)
> > Preliminary: | MT-Safe | AS-Unsafe lock | AC-Unsafe lock fd mem | See POSIX
> > Safety Concepts.
> > 
> > But this is a non-Async-Signal here we are talking about so this is safe and
> > a bug in tsan for not realizing that.
> 
> Well, in this example the signal is synchonous,
> but I see the same problem also when the stack overflows.

Stack overflow is still synchonous.  But really there is not much to be done
with a stack overflow.  it is hard for anything to do with both stack overflow
not in malloc and one in malloc unless you know you are not in malloc.  Still
not a bug which is fixable easily.

Still a BUG in tsan for reporting a non bug.  Please report this to TSAN for
reporting a non BUG.

Thanks,
Andrew Pinski

[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free

[bernd.edlinger at hotmail dot de]

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

--- Comment #9 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Sorry, Andrew,

a deadlock in the Ada exception handler is an Ada BUG
by definition.

Even if YOU can't fix it easily.

The memory could be pre-allocated as the call stack
and we should make it to the point where the user code
starts.  If they call malloc then that's no more our
problem.

Please stop this now.

I still dont see what's wrong with tsan here, the signal could
easily be from a kill -SIGSEGV .

Thanks
Bernd.

[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Bernd Edlinger from comment #9)
> I still dont see what's wrong with tsan here, the signal could
> easily be from a kill -SIGSEGV .

Because this is while executing in the synchonous signal form.  Yes TSAN should
realize that and not report it.

[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free

[bernd.edlinger at hotmail dot de]

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

--- Comment #11 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Sorry.

again the test case c380004
just with this little addition

begin
    Test ("C380004",
          "Check evaluation of discriminant expressions " &
             "when the constraint depends on a discriminant, " &
             "and the discriminants have defaults - discriminant-dependent" &
             "entry families and protected components");


    Comment ("Discriminant-dependent entry families for task types");

+   delay 60.0;

    F1_Poe := 18;


ed@w-ed:~/gnu/gcc-test$ ./c380004 &
[1] 20972
ed@w-ed:~/gnu/gcc-test$ 
,.,. C380004 ACATS 2.5 15-01-03 10:17:46
---- C380004 Check evaluation of discriminant expressions when the
                constraint depends on a discriminant, and the
                discriminants have defaults -
                discriminant-dependententry families and protected
                components.
   - C380004 Discriminant-dependent entry families for task types.

ed@w-ed:~/gnu/gcc-test$ ps
  PID TTY          TIME CMD
20842 pts/9    00:00:00 bash
20972 pts/9    00:00:00 c380004
20974 pts/9    00:00:00 ps
ed@w-ed:~/gnu/gcc-test$ kill -SIGSEGV 20972
ed@w-ed:~/gnu/gcc-test$ ==================
WARNING: ThreadSanitizer: signal-unsafe call inside of a signal (pid=20972)
    #0 malloc ../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors.cc:491
(libtsan.so.0+0x000000025c33)
    #1 __gnat_malloc /home/ed/gnu/gcc-build/gcc/ada/rts/s-memory.adb:92
(c380004+0x000000436ab0)
    #2 system__task_primitives__operations__timed_delay
/home/ed/gnu/gcc-build/gcc/ada/rts/s-taprop.adb:597 (c380004+0x00000041de9f)
    #3 main /home/ed/gnu/gcc-test/b~c380004.adb:304 (c380004+0x000000404138)

SUMMARY: ThreadSanitizer: signal-unsafe call inside of a signal
/home/ed/gnu/gcc-build/gcc/ada/rts/s-memory.adb:92 __gnat_malloc
==================
==================
WARNING: ThreadSanitizer: signal-unsafe call inside of a signal (pid=20972)
    #0 malloc ../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors.cc:491
(libtsan.so.0+0x000000025c33)
    #1 <null> <null> (ld-linux-x86-64.so.2+0x00000000deab)
    #2 system__task_primitives__operations__timed_delay
/home/ed/gnu/gcc-build/gcc/ada/rts/s-taprop.adb:597 (c380004+0x00000041de9f)
    #3 main /home/ed/gnu/gcc-test/b~c380004.adb:304 (c380004+0x000000404138)

SUMMARY: ThreadSanitizer: signal-unsafe call inside of a signal ??:0 ??
==================

[1]+  Aborted                 (core dumped) ./c380004
ed@w-ed:~/gnu/gcc-test$ 


Is this asynchronous enough for you?

[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger <bernd.edlinger at hotmail dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #12 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Andrew,

please stop setting this bug to INVALID all the time
that is not really funny any more.

And I don't see, why this cant be fixed at all,
there are only one or two memory allocations that have to be
be pre-allocated in some kind of signal safe memory pool.

Just to prove the concept I changed the test case c380004
to do some memory allocations while waiting for the
asynchronous signal.

--- ../gcc-trunk/gcc/testsuite/ada/acats/tests/c3/c380004.a    2014-05-24
19:26:48.763568674 +0200
+++ c380004.adb    2015-01-03 11:41:04.198306842 +0100
@@ -36,6 +36,7 @@
 --!
 with Report;
 use Report;
+with Unchecked_Deallocation;
 procedure C380004 is

     type Rec (D1, D2 : Positive) is
@@ -180,7 +181,9 @@
         end;
     end Check;

-
+   type P is access Rec;
+   procedure Deallocate is new Unchecked_Deallocation(Rec, P);
+   pp : P;
 begin
     Test ("C380004",
           "Check evaluation of discriminant expressions " &
@@ -190,6 +193,11 @@


     Comment ("Discriminant-dependent entry families for task types");
+    for I in 1..1000000000 loop
+    pp := new Rec(1,2);
+    Deallocate(pp);
+    end loop;
+--  delay 60.0;

     F1_Poe := 18;



usually I get this:

ed@w-ed:~/gnu/gcc-test$ ./c380004 &
[1] 21589
ed@w-ed:~/gnu/gcc-test$ 
,.,. C380004 ACATS 2.5 15-01-03 11:45:42
---- C380004 Check evaluation of discriminant expressions when the
                constraint depends on a discriminant, and the
                discriminants have defaults -
                discriminant-dependententry families and protected
                components.
   - C380004 Discriminant-dependent entry families for task types.

ed@w-ed:~/gnu/gcc-test$ killall -SIGSEGV c380004
   * C380004 Unexpected exception.
**** C380004 FAILED ****************************.
ed@w-ed:~/gnu/gcc-test$ 
[1]+  Fertig                  ./c380004
ed@w-ed:~/gnu/gcc-test$

but after several re-tries the killed process freezes:


ed@w-ed:~/gnu/gcc-test$ ./c380004 &
[1] 21592
ed@w-ed:~/gnu/gcc-test$ 
,.,. C380004 ACATS 2.5 15-01-03 11:45:46
---- C380004 Check evaluation of discriminant expressions when the
                constraint depends on a discriminant, and the
                discriminants have defaults -
                discriminant-dependententry families and protected
                components.
   - C380004 Discriminant-dependent entry families for task types.

ed@w-ed:~/gnu/gcc-test$ 
ed@w-ed:~/gnu/gcc-test$ killall -SIGSEGV c380004
ed@w-ed:~/gnu/gcc-test$ 
ed@w-ed:~/gnu/gcc-test$ 
ed@w-ed:~/gnu/gcc-test$ ps
  PID TTY          TIME CMD
 2244 pts/0    00:00:00 bash
21592 pts/0    00:00:01 c380004
21596 pts/0    00:00:00 ps

ed@w-ed:~/gnu/gcc-test$ sudo bash
[sudo] password for ed: 
root@w-ed:~/gnu/gcc-test# gdb
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) attach 21592
Attaching to process 21592
Reading symbols from /home/ed/gnu/gcc-test/c380004...done.
Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...Reading symbols
from /usr/lib/debug//lib/x86_64-linux-gnu/libpthread-2.19.so...done.
done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Loaded symbols for /lib/x86_64-linux-gnu/libpthread.so.0
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...Reading symbols from
/usr/lib/debug//lib/x86_64-linux-gnu/libc-2.19.so...done.
done.
Loaded symbols for /lib/x86_64-linux-gnu/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from
/usr/lib/debug//lib/x86_64-linux-gnu/ld-2.19.so...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
__lll_lock_wait_private ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
95    ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: Datei oder
Verzeichnis nicht gefunden.
(gdb) bt
#0  __lll_lock_wait_private ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
#1  0x00007f3549a8d84a in _L_lock_12779 () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007f3549a8b225 in __GI___libc_malloc (bytes=704) at malloc.c:2887
#3  0x00000000004310d1 in <__gnat_malloc> (size=size@entry=704)
    at s-memory.adb:92
#4  0x0000000000439c70 in system.exceptions.machine.new_occurrence ()
    at s-excmac.ads:183
#5  0x00000000004242c1 in
ada.exceptions.exception_propagation.allocate_occurrence () at a-exexpr.adb:188
#6  0x000000000042521c in ada.exceptions.raise_with_location_and_msg (
    e=0x65c8e0 <storage_error>, f=f@entry=(const system__address) 0x4437a0, 
    l=l@entry=139, c=c@entry=0, m=m@entry=(const system__address) 0x444260)
    at a-except.adb:1159
#7  0x00000000004251fa in <__gnat_raise_storage_error_msg> (
    file=file@entry=(const system__address) 0x4437a0, line=line@entry=139, 
    msg=msg@entry=(const system__address) 0x444260) at a-except.adb:1144
#8  0x00000000004254bf in <__gnat_rcheck_SE_Explicit_Raise> (
    file=file@entry=(const system__address) 0x4437a0, line=line@entry=139)
    at a-except.adb:1438
#9  0x0000000000421388 in system.interrupt_management.notify_exception (
    signo=11, siginfo=<optimized out>, 
    ucontext=(const system__address) 0x664540) at s-intman.adb:139
---Type <return> to continue, or q <return> to quit---
#10 <signal handler called>
#11 0x00007f3549a88db0 in _int_malloc (av=0x7f3549dc7760 <main_arena>, bytes=8)
    at malloc.c:3355
#12 0x00007f3549a8b230 in __GI___libc_malloc (bytes=8) at malloc.c:2891
#13 0x00000000004310d1 in <__gnat_malloc> (size=<optimized out>)
    at s-memory.adb:92
#14 0x0000000000408117 in c380004 () at c380004.adb:197
(gdb)

[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-01-04
                 CC|                            |ebotcazou at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #13 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Asynchronous signals aren't supported in Ada so no point in discussing them.

This is a known generic issue but fixing it properly is not straightforward.

[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free

[bernd.edlinger at hotmail dot de]

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

--- Comment #14 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
hmm, ok, but how about this:

--- ../gcc-trunk/gcc/testsuite/ada/acats/tests/cb/cb1010d.ada    2014-05-24
19:26:45.338568486 +0200
+++ cb1010d.adb    2015-01-04 12:55:21.458653242 +0100
@@ -29,14 +29,23 @@
 -- JRK 8/30/85

 WITH REPORT; USE REPORT;
+WITH UNCHECKED_DEALLOCATION;

 PROCEDURE CB1010D IS

      N : INTEGER := IDENT_INT (1);
      M : INTEGER := IDENT_INT (0);

+     TYPE P IS ACCESS INTEGER;
+     PROCEDURE DEALLOCATE IS NEW Unchecked_Deallocation(INTEGER, P);
+
      PROCEDURE OVERFLOW_STACK IS
+          X : P;       
      BEGIN
+          X := new INTEGER;
+          X.ALL := 1;
+          DEALLOCATE (X);
+
           N := N + M;
           IF N > M THEN       -- ALWAYS TRUE.
                OVERFLOW_STACK;


ed@w-ed:~/gnu/gcc-test$ gdb ./cb1010d 
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./cb1010d...done.
(gdb) r
Starting program: /home/ed/gnu/gcc-test/cb1010d 

,.,. CB1010D ACATS 2.5 15-01-04 12:56:58
---- CB1010D CHECK THAT STORAGE_ERROR IS RAISED WHEN STORAGE FOR THE
                EXECUTION OF A SUBPROGRAM IS INSUFFICIENT.

Program received signal SIGSEGV, Segmentation fault.
_int_malloc (av=0x7ffff7dd3760 <main_arena>, bytes=4) at malloc.c:3302
3302    malloc.c: Datei oder Verzeichnis nicht gefunden.
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
__lll_lock_wait_private ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
95    ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: Datei oder
Verzeichnis nicht gefunden.
(gdb) q
A debugging session is active.

    Inferior 1 [process 9469] will be killed.

Quit anyway? (y or n) y
ed@w-ed:~/gnu/gcc-test$ LANG=C
ed@w-ed:~/gnu/gcc-test$ gdb ./cb1010d 
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./cb1010d...done.
(gdb) r
Starting program: /home/ed/gnu/gcc-test/cb1010d 

,.,. CB1010D ACATS 2.5 15-01-04 12:57:19
---- CB1010D CHECK THAT STORAGE_ERROR IS RAISED WHEN STORAGE FOR THE
                EXECUTION OF A SUBPROGRAM IS INSUFFICIENT.

Program received signal SIGSEGV, Segmentation fault.
_int_malloc (av=0x7ffff7dd3760 <main_arena>, bytes=4) at malloc.c:3302
3302    malloc.c: No such file or directory.
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
__lll_lock_wait_private ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
95    ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such file or
directory.
(gdb) bt
#0  __lll_lock_wait_private ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
#1  0x00007ffff7a9984a in _L_lock_12779 () at malloc.c:5206
#2  0x00007ffff7a97225 in __GI___libc_malloc (bytes=704) at malloc.c:2887
#3  0x0000000000415881 in <__gnat_malloc> (size=size@entry=704)
    at s-memory.adb:92
#4  0x000000000041d480 in system.exceptions.machine.new_occurrence ()
    at s-excmac.ads:183
#5  0x0000000000409843 in
ada.exceptions.exception_propagation.allocate_occurrence () at a-exexpr.adb:188
#6  0x000000000040a6b5 in ada.exceptions.create_occurrence_from_signal_handler
    (e=0x636b60 <storage_error>, m=(const system__address) 0x429350)
    at a-except.adb:1058
#7  0x000000000040a702 in ada.exceptions.raise_from_signal_handler (
    e=<optimized out>, m=<optimized out>) at a-except.adb:1093
#8  <signal handler called>
#9  _int_malloc (av=0x7ffff7dd3760 <main_arena>, bytes=4) at malloc.c:3302
#10 0x00007ffff7a97230 in __GI___libc_malloc (bytes=4) at malloc.c:2891
#11 0x0000000000415881 in <__gnat_malloc> (size=<optimized out>)
    at s-memory.adb:92
#12 0x0000000000407237 in cb1010d.overflow_stack () at cb1010d.adb:45
#13 0x00000000004072be in cb1010d.overflow_stack () at cb1010d.adb:51
#14 0x00000000004072be in cb1010d.overflow_stack () at cb1010d.adb:51
#15 0x00000000004072be in cb1010d.overflow_stack () at cb1010d.adb:51
#16 0x00000000004072be in cb1010d.overflow_stack () at cb1010d.adb:51
#17 0x00000000004072be in cb1010d.overflow_stack () at cb1010d.adb:51
#18 0x00000000004072be in cb1010d.overflow_stack () at cb1010d.adb:51
#19 0x00000000004072be in cb1010d.overflow_stack () at cb1010d.adb:51
#20 0x00000000004072be in cb1010d.overflow_stack () at cb1010d.adb:51
#21 0x00000000004072be in cb1010d.overflow_stack () at cb1010d.adb:51
#22 0x00000000004072be in cb1010d.overflow_stack () at cb1010d.adb:51
#23 0x00000000004072be in cb1010d.overflow_stack () at cb1010d.adb:51
#24 0x00000000004072be in cb1010d.overflow_stack () at cb1010d.adb:51
#25 0x00000000004072be in cb1010d.overflow_stack () at cb1010d.adb:51
#26 0x00000000004072be in cb1010d.overflow_stack () at cb1010d.adb:51
#27 0x00000000004072be in cb1010d.overflow_stack () at cb1010d.adb:51
#28 0x00000000004072be in cb1010d.overflow_stack () at cb1010d.adb:51
#29 0x00000000004072be in cb1010d.overflow_stack () at cb1010d.adb:51
#30 0x00000000004072be in cb1010d.overflow_stack () at cb1010d.adb:51

Deadlock: the exception is synchronous, but within malloc...

[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free

[bernd.edlinger at hotmail dot de]

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

--- Comment #15 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
you could avoid that scenario by probing say 4K of stack in __gnat_malloc ?

[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free

[ebotcazou at gcc dot gnu.org]

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

--- Comment #16 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> you could avoid that scenario by probing say 4K of stack in __gnat_malloc ?

No, the stack checking model is to probe sufficiently ahead in the user code by
means of -fstack-check but not in the run time.  Instead the run time should
have a bounded stack usage and avoid calling malloc in these scenarios.

[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free

[bernd.edlinger at hotmail dot de]

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

--- Comment #17 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Oh, I see: I forgot to add -fstack-check.

After re-compiling with -fstack-check the modified test case passes.

[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free

[bernd.edlinger at hotmail dot de]

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

--- Comment #18 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Hi Eric,

if I use kill -11, I would be really surprised to see
the process freeze.

It would be good to look at siginfo->si_code
and _not_ continue the normal exception handling
when the si_code is SI_USER or anything <= 0.

If you receive a signal 11, with si_code == SI_USER,
you can be sure that is sent directly from me,
and I want the process to immediately stop doing what it does
currently and create a core file for later analysis.

I found a pointer in the internet, how to
handle SIGSEGV and still create a code file,
sounds interesting.

http://www.alexonlinux.com/how-to-handle-sigsegv-but-also-generate-core-dump

The idea is to just set the signal hander back to default
and raise the signal again.

Bernd.

[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free

[ebotcazou at gcc dot gnu.org]

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

--- Comment #19 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> if I use kill -11, I would be really surprised to see
> the process freeze.
> 
> It would be good to look at siginfo->si_code
> and _not_ continue the normal exception handling
> when the si_code is SI_USER or anything <= 0.
> 
> If you receive a signal 11, with si_code == SI_USER,
> you can be sure that is sent directly from me,
> and I want the process to immediately stop doing what it does
> currently and create a core file for later analysis.

Possibly, but that's a QoA issue and I'm not sure people really care.