fork() is not async-signal-safe and thus cannot be safely called from a signal handler, the crash handler does this.
signal(7) lists fork as safe, no?
signal(7) is probably out of date, see https://sourceware.org/bugzilla/show_bug.cgi?id=4737 and https://www.opengroup.org/austin/docs/austin_446.txt Although I guess the removal of fork() from the async-signal-safe list and the addition of posix_spawn() may not be fully ratified yet. On the other hand, glibc can deadlock if you do it.
Bugger. The signal handler calls fork twice. Second time to launch a shell, we could use posix_spawn here. But the first time it forks to kill itself and dump core. posix_spawn does not really work for that case.
Hmm, I wonder if we can instead just invoke the syscall directly, foregoing glibc's wrapper around it. Of course this would mean to forego most other glibc apis in the child then, too.
Why not use siglongjmp() to leave the signal handler and then fork()?
longjmp() and siglongjmp() are themselves not async-signal-safe and thus cannot be called from a signal handler.
fork() replaced with syscall(__NR_CLONE, ...) in http://cgit.freedesktop.org/systemd/systemd/commit/?id=ee05e7795b. I think this should be OK now.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.