surprising SIGQUIT behavior "This build does not support backtraces."
I hit ctrl-\ to send a hard SIGQUIT to my program, which I knew does not install a handler for that and wanted to exit immediately (w/o running its usual SIGINT handler), and was surprised to see "This build does not support backtraces." and the program contining to run.
I happened to have run my program from a shell script, and the SIGQUIT terminated the shell that had run it, which left my program running in a kind of backgrounded state where it contended with my interactive shell. And my program happened to have run another program and was itself surprised to see that program, which also received the SIGQUIT, exiting unexpectedly with an unusual exit code.
I think there's a reasonable expectation that SIGQUIT leads to a prompt terminatation of the program, with or without a core dump or something associated with a core dump such as a backtrace. Leaving the program running and printing out an unusual (and untranslated BTW) message to stderr has a high potential to exercise unusual code paths. Some programs may have a good reason to not exit on SIGQUIT, but then the program has to be designed to work that way. ghc is assuming any program will work acceptably if it keeps running after a SIGQUIT, and that is not the case.
In Signals.c, I'd suggest only installing the SIGQUIT handler #if USE_LIBDW. Or, if it's important to communicate the the user that it was not built with backtrace support, it could display the message and then exit.
(It looks like the program might keep running when built with LIBDW too, and maybe that's intentional in order to see repeated backtraces, but I think my reasoning on prompt termination could also apply there.)
Steps to reproduce
Start a long-running git-annex operation, like a "git annex add" in a directory with ots of files, and send it a SIGQUIT.
- GHC version used: 8.6.5 from Debian
- Operating System: Linux
- System Architecture: 864-64