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
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).
The manual is wrong and needs fixing. Since glibc 2.27 we've been AS-safe in that we no longer flush.
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.
(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.
Posted for review: https://sourceware.org/pipermail/libc-alpha/2020-September/117934.html