Usage of non-async signal safe functions in signal handlers

[elextr]

Prompted by #9063 I did a quick check of all the signal handlers (that I can find) for unsafe calls (not in this list). These are the ones I found from quick (mostly Linux only) inspection.

• sigint_handler() uses fputs() several times.
• sigdie_handler() uses ios_printf() which does not protect its buffer manipulations from signal interrupts.

I also noticed that the windows _exception_handler() uses ios_puts() a lot but I am not sure if its ok on windows.

I have not had time to check that jl_errorf() and jl_throw() are safe but they are used a lot.

[vtjnash]

the window's function is fine. since it's not an async signal handler, but a fault recovery filter. as long as the libc and ios manage to avoid throwing programming errors around, it won't cause any issues.

the fputs in the first sigint_handler above is also only for windows, and thus only handles the equivalent of SIGINT. if the fputs are executed, then it is because we just discovered that julia is in a very invalid and corrupt state. we also return 0, which tells windows to terminate our program (technically, we would fall through to the next SIGINT handler, but there aren't any more, so we just get killed off).

that leaves the sigdie_handler. most of the signals it handles are already fatal. if we happen to be in a state where we tried to call malloc but couldn't get the lock, we might freeze waiting for the thread instead of dieing immediately. annoying, but not particularly devastating. others, like those handled by _exception_handler, are triggered by certain invalid operations. those shouldn't be getting thrown by libc or ios, so those are also OK.

that does leave SIGINFO though. it appears from the list you point to that we could perhaps replace printf with write. that does leave jlbacktrace however, which needs to do a lot of allocation and other "risky" operations.

ideas are welcome.

[elextr]

the window's function is fine. since it's not an async signal handler, but a fault recovery filter.

Ok.

if the fputs are executed, then it is because we just discovered that julia is in a very invalid and corrupt state. we also return 0, which tells windows to terminate our program

Ok. Theoretically there is a chance of the fputs not working if a previous fputs was interrupted, but as Julia is terminating its not the end of the world if the message doesn't happen this time. Next time hopefully the interrupt won't happen in exactly the same place.

replace printf with write

yes, thats the usual fix, but of course write is a lot less convenient than printf.

One solution to the backtrace problem I have seen is to pre-allocate the space on the way down the call chain, so backtraces can work without allocation. But its a lot of work to make everything do that, and to release the memory again correctly, and of course it reserves memory that we hope will never get used. I think it would also be hard to apply to C/Fortran functions in system libraries.