SignalHandling returns from SEGFAULT signal handler

[danielk]

If you return from a SIGFAULT, SIGFPE, SIGBUS, or SIGILL the offending code is re-run and the signal is raised again.

If the fault occurs in the the UI thread where SignalHandler::handleSignal() is run in it will never run since we never get the opportunity to continue on to where the QSocketNotifier events are handled.

This leads the write() in SignalHandler::signalHandler() to block forever, deadlocking the UI thread.

[danielk]

Proof-of-concept fix.

[Daniel Thor Kristjansson <danielk@…>]

In 546fdac8d1e952422c91278be3187ae87aded28e/mythtv:

Refs #10841. A fix for SEGFAULT handling.

We may want to handle this differently later, but this works.
We don't return from signalHandler if the signal is SEGV, ILL, BUS, or FPE.
This ensures the signal isn't immediately re-raised on return.
Also, after waiting 1 second for any cleanup actions which will
only happen if this signal didn't occur in the UI thread, we
call the default handler which will generate a core if necessary
and then exit the program.

[Daniel Thor Kristjansson <danielk@…>]

In 6f218b1ab4ad067f564eb07919560970cbb77de2/mythtv:

Refs #10841. Add stdlib include for free.

[Daniel Thor Kristjansson <danielk@…>]

In 62f3c643d80e617aa718421795ca3ac216e3c7cc/mythtv:

Refs #10841. Define SIGBUS as SIGSEGV on windows systems.

[beirdo]

I think what you have so far will work, but I'm considering restructuring it so the signal handlers are in their own thread, which should simplify things a bit. If this hasn't been changed by Aug 1, please remind me to close it as fixed :)