Created attachment 7372 [details] trivial 1/0 reproducer When SIGFPE happens in GDB (for example due to corrupted DWARF file): Actual: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 22602 jkratoch 20 0 243188 90680 39960 R 97.3 1.5 0:12.50 gdb + GDB under GDB: Program received signal SIGFPE, Arithmetic exception. 0x00000000007d076e in process_die (die=0x2531c40, cu=0x23d1b80) at dwarf2read.c:8031 8031 volatile int i=a/b; (gdb) _ Expected: ../../gdb/dwarf2read.c:8031: internal-error: A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) _
The master branch has been updated by Andrew Burgess <aburgess@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=fb550a919a88bf4e3950dd7bcdf72f0a18d94206 commit fb550a919a88bf4e3950dd7bcdf72f0a18d94206 Author: Andrew Burgess <andrew.burgess@embecosm.com> Date: Thu Jun 10 10:44:43 2021 +0100 gdb: terminate upon receipt of SIGFPE GDB's SIGFPE handling is broken, this is PR gdb/16505 and PR gdb/17891. We currently try to use an async event token to process SIGFPE. So, when a SIGFPE arrives the signal handler calls mark_async_signal_handler then returns, effectively ignoring the signal (for now). The intention is that later the event loop will see that the async token associated with SIGFPE has been marked and will call the async handler, which just throws an error. The problem is that SIGFPE is not safe to ignore. Ignoring a SIGFPE (unless it is generated artificially, e.g. by raise()) is undefined behaviour, after ignoring the signal on many targets we return to the instruction that caused the SIGFPE to be raised, which immediately causes another SIGFPE to be raised, we get stuck in an infinite loop. The behaviour is certainly true on x86-64. To view this behaviour I simply added some dummy code to GDB that performed an integer divide by zero, compiled this on x86-64 GNU/Linux, ran GDB and saw GDB hang. In this commit, I propose to remove all special handling of SIGFPE and instead just let GDB make use of the default SIGFPE action, that is, to terminate the process. The only user visible change here should be: - If a user sends a SIGFPE to GDB using something like kill, previously GDB would just print an error and remain alive, now GDB will terminate. This is inline with what happens if the user sends GDB a SIGSEGV from kill though, so I don't see this as an issue. - If a bug in GDB causes a real SIGFPE, previously the users GDB session would hang. Now the GDB session will terminate. Again, this is inline with what happens if GDB receives a SIGSEGV due to an internal bug. In bug gdb/16505 there is mention that it would be nice if GDB did more than just terminate when receiving a fatal signal. I haven't done that in this commit, but later commits will move in that direction. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16505 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17891
(In reply to Sourceware Commits from comment #1) > The master branch has been updated by Andrew Burgess > <aburgess@sourceware.org>: > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git; > h=fb550a919a88bf4e3950dd7bcdf72f0a18d94206 > > commit fb550a919a88bf4e3950dd7bcdf72f0a18d94206 > Author: Andrew Burgess <andrew.burgess@embecosm.com> > Date: Thu Jun 10 10:44:43 2021 +0100 > > gdb: terminate upon receipt of SIGFPE > > GDB's SIGFPE handling is broken, this is PR gdb/16505 and > PR gdb/17891. > > We currently try to use an async event token to process SIGFPE. So, > when a SIGFPE arrives the signal handler calls > mark_async_signal_handler then returns, effectively ignoring the > signal (for now). > > The intention is that later the event loop will see that the async > token associated with SIGFPE has been marked and will call the async > handler, which just throws an error. > > The problem is that SIGFPE is not safe to ignore. Ignoring a > SIGFPE (unless it is generated artificially, e.g. by raise()) is > undefined behaviour, after ignoring the signal on many targets we > return to the instruction that caused the SIGFPE to be raised, which > immediately causes another SIGFPE to be raised, we get stuck in an > infinite loop. The behaviour is certainly true on x86-64. > > To view this behaviour I simply added some dummy code to GDB that > performed an integer divide by zero, compiled this on x86-64 > GNU/Linux, ran GDB and saw GDB hang. > > In this commit, I propose to remove all special handling of SIGFPE and > instead just let GDB make use of the default SIGFPE action, that is, > to terminate the process. > > The only user visible change here should be: > > - If a user sends a SIGFPE to GDB using something like kill, > previously GDB would just print an error and remain alive, now GDB > will terminate. This is inline with what happens if the user > sends GDB a SIGSEGV from kill though, so I don't see this as an > issue. > > - If a bug in GDB causes a real SIGFPE, previously the users GDB > session would hang. Now the GDB session will terminate. Again, > this is inline with what happens if GDB receives a SIGSEGV due to > an internal bug. > > In bug gdb/16505 there is mention that it would be nice if GDB did > more than just terminate when receiving a fatal signal. I haven't > done that in this commit, but later commits will move in that > direction. > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16505 > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17891 Can this be closed now?