Made signal handling more uniform during crashes.

[naelstrof]

Fixes #82102

I've learned that signal is heavily implementation specific. According to the cppreference docs:

When signal handler is set to a function and a signal occurs, it is implementation defined whether signal(sig, SIG_DFL) will be executed immediately before the start of signal handler. Also, the implementation can prevent some implementation-defined set of signals from occurring while the signal handler runs.

This means that we won't know if further exceptions during crash handling will be ignored, cause loops, lockups, or crashes since it's completely implementation specific.

It also states

POSIX recommends sigaction instead of signal, due to its underspecified behavior and significant implementation variations, regarding signal delivery while a signal handler is executed.

I'm not sure if sigaction is a good fit for godot, since godot is multi-platform and sigaction is not. And it's nice keeping the crash handlers somewhat similar in design when possible.

So now for my proposed solution: a very simple fix is to enforce the behavior of signal by starting the crash handler with

static void handle_crash(int sig) {
    signal(SIGSEGV, SIG_DFL);
    signal(SIGFPE,  SIG_DFL);
    signal(SIGILL,  SIG_DFL);
...

This prevents further fatal errors from initiating patty-cake with the kernel for most implementations. The trade-off being that we still won't know if the implementation is currently ignoring any of the signals.

I think making it work for all implementations would require a reassessment for using sigaction.

Regardless, this change should make the crash handlers more sane without being complicated. Tested it and it works okay:

[jams3223]

You forgot to put a blank line between line 77 and line 78, small stuff but just to keep the code clean.

[naelstrof]

Added the space, how's that?

[jams3223]

Added the space, how's that?

Sorry i meant a blank line.

[naelstrof]

This pull request should also fix the freeze (but not the true source of the problem) for the following issues:
#54426
#77109

[Calinou]

Does SIGABRT also need to be handled? See #77286.

[naelstrof]

Does SIGABRT also need to be handled? See #77286.

In general, Godot's crash handler is several steps removed from being signal-safe. Handling more signals right now means more opportunities to mishandle them and cause lockups.

The default behavior of fatal signals is to simply crash, which is very safe. However it comes with the tradeoff of not providing any stack trace information for the user.

Ideally, Godot's crash handler would first be made signal-safe, then all signals that could be reasonably caused by a programmer's code should print a stack-trace to help identify what's wrong.

tldr Not right now, but yes after improvements have been made to the crash handler.

[naelstrof]

I've created a new issue to address the lack of signal safety here for further discussion: #82418

[bruvzg]

Seems reasonable to me.

[akien-mga]

Thanks! And congrats for your first merged Godot contribution 🎉