diff options
| author | Pedro Alves <palves@redhat.com> | 2015-04-10 10:36:23 +0100 |
|---|---|---|
| committer | Pedro Alves <palves@redhat.com> | 2015-04-10 10:36:23 +0100 |
| commit | 8d707a12ef51ba5f4c3c6a52532e903da7a56b8b (patch) | |
| tree | 37c565150854b4dfaee0f9cb7968784d397b6396 /gdb/infrun.c | |
| parent | ef713951c571c8490ca57c17c88785c6df1ed840 (diff) | |
| download | gdb-8d707a12ef51ba5f4c3c6a52532e903da7a56b8b.zip gdb-8d707a12ef51ba5f4c3c6a52532e903da7a56b8b.tar.gz gdb-8d707a12ef51ba5f4c3c6a52532e903da7a56b8b.tar.bz2 | |
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.
Diffstat (limited to 'gdb/infrun.c')
| -rw-r--r-- | gdb/infrun.c | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/gdb/infrun.c b/gdb/infrun.c index d52b8ad..3fcc55f 100644 --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -4961,7 +4961,8 @@ process_event_stop_test (struct execution_control_state *ecs) struct breakpoint *sr_bp = ecs->event_thread->control.step_resume_breakpoint; - if (sr_bp->loc->permanent + if (sr_bp != NULL + && sr_bp->loc->permanent && sr_bp->type == bp_hp_step_resume && sr_bp->loc->address == ecs->event_thread->prev_pc) { |