[Bug libc/26275] New: abort(3) is not signal-safe

[Bug libc/26275] New: abort(3) is not signal-safe

[yd-huang at outlook dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26275

            Bug ID: 26275
           Summary: abort(3) is not signal-safe
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: critical
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: yd-huang at outlook dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

abort(3) is required to be signal-safe by POSIX, but it's not, according to:
1.
https://www.gnu.org/software/libc/manual/html_node/Aborting-a-Program.html#Aborting-a-Program
2.
https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/abort.c;h=df98782dd7ea6c1476184a365bd9f3954f481a18;hb=refs/heads/master#l54

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/26275] abort(3) is not signal-safe

[yd-huang at outlook dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26275

hyd-dev <yd-huang at outlook dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/26275] abort(3) is not signal-safe

[yd-huang at outlook dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26275

--- Comment #1 from hyd-dev <yd-huang at outlook dot com> ---
In addition to POSIX
(https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03_03),
it's also required to be signal-safe by ISO C and ISO C++ 17
(https://github.com/cplusplus/draft/blob/n4659/source/support.tex#L1643-L1644).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/26275] abort(3) is not signal-safe

[jistone at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26275

Josh Stone <jistone at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jistone at redhat dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/26275] abort(3) is not signal-safe

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26275

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #2 from Carlos O'Donell <carlos at redhat dot com> ---
The manual is wrong and needs fixing.

Since glibc 2.27 we've been AS-safe in that we no longer flush.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/26275] abort(3) is not signal-safe

[yd-huang at outlook dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26275

--- Comment #3 from hyd-dev <yd-huang at outlook dot com> ---
But what about the lock:
https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/abort.c;h=df98782dd7ea6c1476184a365bd9f3954f481a18;hb=refs/heads/master#l54?
Holding that lock is not signal-safe, even it is recursive. For example, a
thread is calls abort(3) and acquires the lock. Then another thread fork(2),
and the child process calls abort(3) and tries to lock the lock, leading to
deadlock.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/26275] abort(3) is not signal-safe

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26275

--- Comment #4 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to hyd-dev from comment #3)
> But what about the lock:
> https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/abort.c;
> h=df98782dd7ea6c1476184a365bd9f3954f481a18;hb=refs/heads/master#l54?
> Holding that lock is not signal-safe, even it is recursive. For example, a
> thread is calls abort(3) and acquires the lock. Then another thread fork(2),
> and the child process calls abort(3) and tries to lock the lock, leading to
> deadlock.

You are correct. I missed the local lock to make abort MT-safe. In this case we
to extend the lock to coordinate with fork like we do with malloc and the stdio
locks. Let me test a quick fix.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/26275] abort(3) is not signal-safe

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26275

--- Comment #5 from Carlos O'Donell <carlos at redhat dot com> ---
Posted for review:
https://sourceware.org/pipermail/libc-alpha/2020-September/117934.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/26275] abort(3) is not signal-safe

[yd-huang at outlook dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26275

hyd-dev <yd-huang at outlook dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yd-huang at outlook dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.