This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug gdb/18225] step past a breakpoint with signal to deliver but handler set to SIG_IGN


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

--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Pedro Alves <palves@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8d707a12ef51ba5f4c3c6a52532e903da7a56b8b

commit 8d707a12ef51ba5f4c3c6a52532e903da7a56b8b
Author: Pedro Alves <palves@redhat.com>
Date:   Fri Apr 10 10:36:23 2015 +0100

    gdb/18216: displaced step+deliver signal, a thread needs step-over, crash

    The problem is that with hardware step targets and displaced stepping,
    "signal FOO" when stopped at a breakpoint steps the breakpoint
    instruction at the same time it delivers a signal.  This results in
    tp->stepped_breakpoint set, but no step-resume breakpoint set.  When
    the next stop event arrives, GDB crashes.  Irrespective of whether we
    should do something more/different to step past the breakpoint in this
    scenario (e.g., PR 18225), it's just wrong to assume there'll be a
    step-resume breakpoint set (and was not the original intention).

    gdb/ChangeLog:
    2015-04-10  Pedro Alves  <palves@redhat.com>

        PR gdb/18216
        * infrun.c (process_event_stop_test): Don't assume a step-resume
        is set if tp->stepped_breakpoint is true.

    gdb/testsuite/ChangeLog:
    2015-04-10  Pedro Alves  <palves@redhat.com>

        PR gdb/18216
        * gdb.threads/multiple-step-overs.exp: Remove expected eof.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]