public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug gdb/18216] New: displaced step+deliver signal, while another thread also needs to step over breakpoint, crashes gdb on hardware step targets
@ 2015-04-08 18:34 palves at redhat dot com
2015-04-08 18:59 ` [Bug gdb/18216] " cvs-commit at gcc dot gnu.org
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: palves at redhat dot com @ 2015-04-08 18:34 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=18216
Bug ID: 18216
Summary: displaced step+deliver signal, while another thread
also needs to step over breakpoint, crashes gdb on
hardware step targets
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: gdb
Assignee: unassigned at sourceware dot org
Reporter: palves at redhat dot com
gdb crashes on hardware step targets, if when we start resuming the target "in
proceed", there are multiple threads that needs to step over a breakpoint, and
we start a displaced set and deliver a signal at the same time (e.g.,
queue-signal), while _another_ thread also needs to step over breakpoint.
This is exact same use case that is mishandled on software single-step (see bug
18214) but it's like a funny mirror: on only happens with displaced stepping.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug gdb/18216] displaced step+deliver signal, while another thread also needs to step over breakpoint, crashes gdb on hardware step targets
2015-04-08 18:34 [Bug gdb/18216] New: displaced step+deliver signal, while another thread also needs to step over breakpoint, crashes gdb on hardware step targets palves at redhat dot com
@ 2015-04-08 18:59 ` cvs-commit at gcc dot gnu.org
2015-04-08 19:06 ` palves at redhat dot com
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2015-04-08 18:59 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=18216
--- Comment #1 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=f3770638ca377ff2bdd7cec2cb239d2909034690
commit f3770638ca377ff2bdd7cec2cb239d2909034690
Author: Pedro Alves <palves@redhat.com>
Date: Wed Apr 8 19:59:03 2015 +0100
Add test for PR18214 and PR18216 - multiple step-overs with queued signals
Both PRs are triggered by the same use case.
PR18214 is about software single-step targets. On those, the 'resume'
code that detects that we're stepping over a breakpoint and delivering
a signal at the same time:
/* Currently, our software single-step implementation leads to different
results than hardware single-stepping in one situation: when stepping
into delivering a signal which has an associated signal handler,
hardware single-step will stop at the first instruction of the
handler,
while software single-step will simply skip execution of the handler.
...
Fortunately, we can at least fix this particular issue. We detect
here the case where we are about to deliver a signal while software
single-stepping with breakpoints removed. In this situation, we
revert the decisions to remove all breakpoints and insert single-
step breakpoints, and instead we install a step-resume breakpoint
at the current address, deliver the signal without stepping, and
once we arrive back at the step-resume breakpoint, actually step
over the breakpoint we originally wanted to step over. */
doesn't handle the case of _another_ thread also needing to step over
a breakpoint. Because the other thread is just resumed at the PC
where it had stopped and a breakpoint is still inserted there, the
thread immediately re-traps the same breakpoint. This test exercises
that. On software single-step targets, it fails like this:
KFAIL: gdb.threads/multiple-step-overs.exp: displaced=off: signal thr3:
continue to sigusr1_handler
KFAIL: gdb.threads/multiple-step-overs.exp: displaced=off: signal thr2:
continue to sigusr1_handler
gdb.log (simplified):
(gdb) continue
Continuing.
Breakpoint 4, child_function_2 (arg=0x0) at
src/gdb/testsuite/gdb.threads/multiple-step-overs.c:66
66 callme (); /* set breakpoint thread 2 here */
(gdb) thread 3
(gdb) queue-signal SIGUSR1
(gdb) thread 1
[Switching to thread 1 (Thread 0x7ffff7fc1740 (LWP 24824))]
#0 main () at src/gdb/testsuite/gdb.threads/multiple-step-overs.c:106
106 wait_threads (); /* set wait-threads breakpoint here */
(gdb) break sigusr1_handler
Breakpoint 5 at 0x400837: file
src/gdb/testsuite/gdb.threads/multiple-step-overs.c, line 31.
(gdb) continue
Continuing.
[Switching to Thread 0x7ffff7fc0700 (LWP 24828)]
Breakpoint 4, child_function_2 (arg=0x0) at
src/gdb/testsuite/gdb.threads/multiple-step-overs.c:66
66 callme (); /* set breakpoint thread 2 here */
(gdb) KFAIL: gdb.threads/multiple-step-overs.exp: displaced=off: signal
thr3: continue to sigusr1_handler
For good measure, I made the test try displaced stepping too. And
then I found it crashes GDB on x86-64 (a hardware step target), but
only when displaced stepping... :
KFAIL: gdb.threads/multiple-step-overs.exp: displaced=on: signal thr1:
continue to sigusr1_handler (PRMS: gdb/18216)
KFAIL: gdb.threads/multiple-step-overs.exp: displaced=on: signal thr2:
continue to sigusr1_handler (PRMS: gdb/18216)
KFAIL: gdb.threads/multiple-step-overs.exp: displaced=on: signal thr3:
continue to sigusr1_handler (PRMS: gdb/18216)
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000000000062a83a in process_event_stop_test (ecs=0x7fff847eeee0) at
src/gdb/infrun.c:4964
4964 if (sr_bp->loc->permanent
Setting up the environment for debugging gdb.
Breakpoint 1 at 0x79fcfc: file src/gdb/common/errors.c, line 54.
Breakpoint 2 at 0x50a26c: file src/gdb/cli/cli-cmds.c, line 217.
(top-gdb) p sr_bp
$1 = (struct breakpoint *) 0x0
(top-gdb) bt
#0 0x000000000062a83a in process_event_stop_test (ecs=0x7fff847eeee0) at
src/gdb/infrun.c:4964
#1 0x000000000062a1af in handle_signal_stop (ecs=0x7fff847eeee0) at
src/gdb/infrun.c:4715
#2 0x0000000000629097 in handle_inferior_event (ecs=0x7fff847eeee0) at
src/gdb/infrun.c:4165
#3 0x0000000000627482 in fetch_inferior_event (client_data=0x0) at
src/gdb/infrun.c:3298
#4 0x000000000064ad7b in inferior_event_handler
(event_type=INF_REG_EVENT, client_data=0x0) at src/gdb/inf-loop.c:56
#5 0x00000000004c375f in handle_target_event (error=0, client_data=0x0)
at src/gdb/linux-nat.c:4658
#6 0x0000000000648c47 in handle_file_event (file_ptr=0x2e0eaa0,
ready_mask=1) at src/gdb/event-loop.c:658
The all-stop-non-stop series fixes this, but meanwhile, this augments
the multiple-step-overs.exp test to cover this, KFAILed.
gdb/testsuite/ChangeLog:
2015-04-08 Pedro Alves <palves@redhat.com>
PR gdb/18214
PR gdb/18216
* gdb.threads/multiple-step-overs.c (sigusr1_handler): New
function.
(main): Install it as SIGUSR1 handler.
* gdb.threads/multiple-step-overs.exp (setup): Remove 'prefix'
parameter. Always use "setup" as prefix. Toggle "set
displaced-stepping" off/on depending on global. Don't switch to
thread 1 here.
(top level): Add displaced stepping "off/on" test axis. Update
"setup" calls. Wrap each subtest with with_test_prefix. Test
continuing with a queued signal in each thread.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug gdb/18216] displaced step+deliver signal, while another thread also needs to step over breakpoint, crashes gdb on hardware step targets
2015-04-08 18:34 [Bug gdb/18216] New: displaced step+deliver signal, while another thread also needs to step over breakpoint, crashes gdb on hardware step targets palves at redhat dot com
2015-04-08 18:59 ` [Bug gdb/18216] " cvs-commit at gcc dot gnu.org
@ 2015-04-08 19:06 ` palves at redhat dot com
2015-04-08 19:08 ` palves at redhat dot com
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: palves at redhat dot com @ 2015-04-08 19:06 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=18216
Pedro Alves <palves at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
Assignee|unassigned at sourceware dot org |palves at redhat dot com
--- Comment #2 from Pedro Alves <palves at redhat dot com> ---
Mine.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug gdb/18216] displaced step+deliver signal, while another thread also needs to step over breakpoint, crashes gdb on hardware step targets
2015-04-08 18:34 [Bug gdb/18216] New: displaced step+deliver signal, while another thread also needs to step over breakpoint, crashes gdb on hardware step targets palves at redhat dot com
` (2 preceding siblings ...)
2015-04-08 19:08 ` palves at redhat dot com
@ 2015-04-08 19:08 ` palves at redhat dot com
2015-04-10 9:38 ` cvs-commit at gcc dot gnu.org
2015-04-10 9:40 ` palves at redhat dot com
5 siblings, 0 replies; 7+ messages in thread
From: palves at redhat dot com @ 2015-04-08 19:08 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=18216
Pedro Alves <palves at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |ASSIGNED
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug gdb/18216] displaced step+deliver signal, while another thread also needs to step over breakpoint, crashes gdb on hardware step targets
2015-04-08 18:34 [Bug gdb/18216] New: displaced step+deliver signal, while another thread also needs to step over breakpoint, crashes gdb on hardware step targets palves at redhat dot com
2015-04-08 18:59 ` [Bug gdb/18216] " cvs-commit at gcc dot gnu.org
2015-04-08 19:06 ` palves at redhat dot com
@ 2015-04-08 19:08 ` palves at redhat dot com
2015-04-08 19:08 ` palves at redhat dot com
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: palves at redhat dot com @ 2015-04-08 19:08 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=18216
Pedro Alves <palves at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |---
--- Comment #3 from Pedro Alves <palves at redhat dot com> ---
Mine.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug gdb/18216] displaced step+deliver signal, while another thread also needs to step over breakpoint, crashes gdb on hardware step targets
2015-04-08 18:34 [Bug gdb/18216] New: displaced step+deliver signal, while another thread also needs to step over breakpoint, crashes gdb on hardware step targets palves at redhat dot com
` (3 preceding siblings ...)
2015-04-08 19:08 ` palves at redhat dot com
@ 2015-04-10 9:38 ` cvs-commit at gcc dot gnu.org
2015-04-10 9:40 ` palves at redhat dot com
5 siblings, 0 replies; 7+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2015-04-10 9:38 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=18216
--- Comment #4 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug gdb/18216] displaced step+deliver signal, while another thread also needs to step over breakpoint, crashes gdb on hardware step targets
2015-04-08 18:34 [Bug gdb/18216] New: displaced step+deliver signal, while another thread also needs to step over breakpoint, crashes gdb on hardware step targets palves at redhat dot com
` (4 preceding siblings ...)
2015-04-10 9:38 ` cvs-commit at gcc dot gnu.org
@ 2015-04-10 9:40 ` palves at redhat dot com
5 siblings, 0 replies; 7+ messages in thread
From: palves at redhat dot com @ 2015-04-10 9:40 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=18216
Pedro Alves <palves at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #5 from Pedro Alves <palves at redhat dot com> ---
Fixed.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-04-10 9:40 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-04-08 18:34 [Bug gdb/18216] New: displaced step+deliver signal, while another thread also needs to step over breakpoint, crashes gdb on hardware step targets palves at redhat dot com
2015-04-08 18:59 ` [Bug gdb/18216] " cvs-commit at gcc dot gnu.org
2015-04-08 19:06 ` palves at redhat dot com
2015-04-08 19:08 ` palves at redhat dot com
2015-04-08 19:08 ` palves at redhat dot com
2015-04-10 9:38 ` cvs-commit at gcc dot gnu.org
2015-04-10 9:40 ` palves at redhat dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).