[Bug gdb/16505] internal SIGFPE busy-CPU locks up GDB

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=16505

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.