2015-01-01 09:32:14 +00:00
|
|
|
# Copyright (C) 2014-2015 Free Software Foundation, Inc.
|
Always pass signals to the right thread
Currently, GDB can pass a signal to the wrong thread in several
different but related scenarios.
E.g., if thread 1 stops for signal SIGFOO, the user switches to thread
2, and then issues "continue", SIGFOO is actually delivered to thread
2, not thread 1. This obviously messes up programs that use
pthread_kill to send signals to specific threads.
This has been a known issue for a long while. Back in 2008 when I
made stop_signal be per-thread (2020b7ab), I kept the behavior -- see
code in 'proceed' being removed -- wanting to come back to it later.
The time has finally come now.
The patch fixes this -- on resumption, intercepted signals are always
delivered to the thread that had intercepted them.
Another example: if thread 1 stops for a breakpoint, the user switches
to thread 2, and then issues "signal SIGFOO", SIGFOO is actually
delivered to thread 1, not thread 2, because 'proceed' first switches
to thread 1 to step over its breakpoint... If the user deletes the
breakpoint before issuing "signal FOO", then the signal is delivered
to thread 2 (the current thread).
"signal SIGFOO" can be used for two things: inject a signal in the
program while the program/thread had stopped for none, bypassing
"handle nopass"; or changing/suppressing a signal the program had
stopped for. These scenarios are really two faces of the same coin,
and GDB can't really guess what the user is trying to do. GDB might
have intercepted signals in more than one thread even (see the new
signal-command-multiple-signals-pending.exp test). At least in the
inject case, it's obviously clear to me that the user means to deliver
the signal to the currently selected thread, so best is to make the
command's behavior consistent and easy to explain.
Then, if the user is trying to suppress/change a signal the program
had stopped for instead of injecting a new signal, but, the user had
changed threads meanwhile, then she will be surprised that with:
(gdb) continue
Thread 1 stopped for signal SIGFOO.
(gdb) thread 2
(gdb) signal SIGBAR
... GDB actually delivers SIGFOO to thread 1, and SIGBAR to thread 2
(with scheduler-locking off, which is the default, because then
"signal" or any other resumption command resumes all threads).
So the patch makes GDB detect that, and ask for confirmation:
(gdb) thread 1
[Switching to thread 1 (Thread 10979)]
(gdb) signal SIGUSR2
Note:
Thread 3 previously stopped with signal SIGUSR2, User defined signal 2.
Thread 2 previously stopped with signal SIGUSR1, User defined signal 1.
Continuing thread 1 (the current thread) with specified signal will
still deliver the signals noted above to their respective threads.
Continue anyway? (y or n)
All these scenarios are covered by the new tests.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-07-25 Pedro Alves <palves@redhat.com>
* NEWS: Mention signal passing and "signal" command changes.
* gdbthread.h (struct thread_suspend_state) <stop_signal>: Extend
comment.
* breakpoint.c (until_break_command): Adjust clear_proceed_status
call.
* infcall.c (run_inferior_call): Adjust clear_proceed_status call.
* infcmd.c (proceed_thread_callback, continue_1, step_once)
(jump_command): Adjust clear_proceed_status call.
(signal_command): Warn if other thread that are resumed have
signals that will be delivered. Adjust clear_proceed_status call.
(until_next_command, finish_command)
(proceed_after_attach_callback, attach_command_post_wait)
(attach_command): Adjust clear_proceed_status call.
* infrun.c (proceed_after_vfork_done): Likewise.
(proceed_after_attach_callback): Adjust comment.
(clear_proceed_status_thread): Clear stop_signal if not in pass
state.
(clear_proceed_status_callback): Delete.
(clear_proceed_status): New 'step' parameter. Only clear the
proceed status of threads the command being prepared is about to
resume.
(proceed): If passed in an explicit signal, override stop_signal
with it. Don't pass the last stop signal to the thread we're
resuming.
(init_wait_for_inferior): Adjust clear_proceed_status call.
(switch_back_to_stepped_thread): Clear the signal if it should not
be passed.
* infrun.h (clear_proceed_status): New 'step' parameter.
(user_visible_resume_ptid): Add comment.
* linux-nat.c (linux_nat_resume_callback): Don't check whether the
signal is in pass state.
* remote.c (append_pending_thread_resumptions): Likewise.
* mi/mi-main.c (proceed_thread): Adjust clear_proceed_status call.
gdb/doc/
2014-07-25 Pedro Alves <palves@redhat.com>
Eli Zaretskii <eliz@gnu.org>
* gdb.texinfo (Signaling) <signal command>: Explain what happens
with multi-threaded programs.
gdb/testsuite/
2014-07-25 Pedro Alves <palves@redhat.com>
* gdb.threads/signal-command-handle-nopass.c: New file.
* gdb.threads/signal-command-handle-nopass.exp: New file.
* gdb.threads/signal-command-multiple-signals-pending.c: New file.
* gdb.threads/signal-command-multiple-signals-pending.exp: New file.
* gdb.threads/signal-delivered-right-thread.c: New file.
* gdb.threads/signal-delivered-right-thread.exp: New file.
2014-07-25 15:57:31 +00:00
|
|
|
|
|
|
|
# This program is free software; you can redistribute it and/or modify
|
|
|
|
# it under the terms of the GNU General Public License as published by
|
|
|
|
# the Free Software Foundation; either version 3 of the License, or
|
|
|
|
# (at your option) any later version.
|
|
|
|
#
|
|
|
|
# This program is distributed in the hope that it will be useful,
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
# GNU General Public License for more details.
|
|
|
|
#
|
|
|
|
# You should have received a copy of the GNU General Public License
|
|
|
|
# along with this program. If not, see <http://www.gnu.org/licenses/>. */
|
|
|
|
|
|
|
|
# Test that "signal FOO" behaves correctly when we have multiple
|
|
|
|
# threads that have stopped for a signal.
|
|
|
|
|
|
|
|
if [target_info exists gdb,nosignals] {
|
|
|
|
verbose "Skipping ${testfile}.exp because of nosignals."
|
|
|
|
return -1
|
|
|
|
}
|
|
|
|
|
|
|
|
standard_testfile
|
|
|
|
|
|
|
|
if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" \
|
|
|
|
executable { debug }] != "" } {
|
|
|
|
return -1
|
|
|
|
}
|
|
|
|
|
|
|
|
# Run the test proper. SCHEDLOCK indicates which variant (around
|
|
|
|
# scheduler-locking) of the test to perform.
|
|
|
|
|
|
|
|
proc test { schedlock } {
|
|
|
|
global srcfile binfile
|
|
|
|
|
|
|
|
with_test_prefix "schedlock $schedlock" {
|
|
|
|
clean_restart ${binfile}
|
|
|
|
|
|
|
|
if ![runto_main] then {
|
|
|
|
fail "Can't run to main"
|
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
|
|
|
gdb_test "handle SIGUSR1 stop print pass"
|
|
|
|
gdb_test "handle SIGUSR2 stop print pass"
|
|
|
|
|
|
|
|
gdb_test "break all_threads_started" "Breakpoint .* at .*$srcfile.*"
|
Linux: Skip thread_db thread event reporting if PTRACE_EVENT_CLONE is supported
[A test I wrote stumbled on a libthread_db issue related to thread
event breakpoints. See glibc PR17705:
[nptl_db: stale thread create/death events if debugger detaches]
https://sourceware.org/bugzilla/show_bug.cgi?id=17705
This patch avoids that whole issue by making GDB stop using thread
event breakpoints in the first place, which is good for other reasons
as well, anyway.]
Before PTRACE_EVENT_CLONE (Linux 2.6), the only way to learn about new
threads in the inferior (to attach to them) or to learn about thread
exit was to coordinate with the inferior's glibc/runtime, using
libthread_db. That works by putting a breakpoint at a magic address
which is called when a new thread is spawned, or when a thread is
about to exit. When that breakpoint is hit, all threads are stopped,
and then GDB coordinates with libthread_db to read data structures out
of the inferior to learn about what happened. Then the breakpoint is
single-stepped, and then all threads are re-resumed. This isn't very
efficient (stops all threads) and is more fragile (inferior's thread
list in memory may be corrupt; libthread_db bugs, etc.) than ideal.
When the kernel supports PTRACE_EVENT_CLONE (which we already make use
of), there's really no need to use libthread_db's event reporting
mechanism to learn about new LWPs. And if the kernel supports that,
then we learn about LWP exits through regular WIFEXITED wait statuses,
so no need for the death event breakpoint either.
GDBserver has been likewise skipping the thread_db events for a long
while:
https://sourceware.org/ml/gdb-patches/2007-10/msg00547.html
There's one user-visible difference: we'll no longer print about
threads being created and exiting while the program is running, like:
[Thread 0x7ffff7dbb700 (LWP 30670) exited]
[New Thread 0x7ffff7db3700 (LWP 30671)]
[Thread 0x7ffff7dd3700 (LWP 30667) exited]
[New Thread 0x7ffff7dab700 (LWP 30672)]
[Thread 0x7ffff7db3700 (LWP 30671) exited]
[Thread 0x7ffff7dcb700 (LWP 30668) exited]
This is exactly the same behavior as when debugging against remote
targets / gdbserver. I actually think that's a good thing (and as
such have listed this in the local/remote parity wiki page a while
ago), as the printing slows down the inferior. It's also a
distraction to keep bothering the user about short-lived threads that
she won't be able to interact with anyway. Instead, the user (and
frontend) will be informed about new threads that currently exist in
the program when the program next stops:
(gdb) c
...
* ctrl-c *
[New Thread 0x7ffff7963700 (LWP 7797)]
[New Thread 0x7ffff796b700 (LWP 7796)]
Program received signal SIGINT, Interrupt.
[Switching to Thread 0x7ffff796b700 (LWP 7796)]
clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:81
81 testq %rax,%rax
(gdb) info threads
A couple of tests had assumptions on GDB thread numbers that no longer
hold.
Tested on x86_64 Fedora 20.
gdb/
2014-01-09 Pedro Alves <palves@redhat.com>
Skip enabling event reporting if the kernel supports
PTRACE_EVENT_CLONE.
* linux-thread-db.c: Include "nat/linux-ptrace.h".
(thread_db_use_events): New function.
(try_thread_db_load_1): Check thread_db_use_events before enabling
event reporting.
(update_thread_state): New function.
(attach_thread): Use it. Check thread_db_use_events before
enabling event reporting.
(thread_db_detach): Check thread_db_use_events before disabling
event reporting.
(find_new_threads_callback): Check thread_db_use_events before
enabling event reporting. Update the thread's state if not using
libthread_db events.
gdb/testsuite/
2014-01-09 Pedro Alves <palves@redhat.com>
* gdb.threads/fork-thread-pending.exp: Switch to the main thread
instead of to thread 2.
* gdb.threads/signal-command-multiple-signals-pending.c (main):
Add barrier around each pthread_create call instead of around all
calls.
* gdb.threads/signal-command-multiple-signals-pending.exp (test):
Set a break on thread_function and have the child threads hit it
one at at a time.
2014-12-16 16:12:25 +00:00
|
|
|
|
|
|
|
# Create threads one at a time, to insure stable thread
|
|
|
|
# numbers between runs and targets.
|
|
|
|
gdb_test "break thread_function" "Breakpoint .* at .*$srcfile.*"
|
|
|
|
gdb_test "continue" "thread_function.*" "thread 2 created"
|
|
|
|
gdb_test "continue" "thread_function.*" "thread 3 created"
|
|
|
|
|
Always pass signals to the right thread
Currently, GDB can pass a signal to the wrong thread in several
different but related scenarios.
E.g., if thread 1 stops for signal SIGFOO, the user switches to thread
2, and then issues "continue", SIGFOO is actually delivered to thread
2, not thread 1. This obviously messes up programs that use
pthread_kill to send signals to specific threads.
This has been a known issue for a long while. Back in 2008 when I
made stop_signal be per-thread (2020b7ab), I kept the behavior -- see
code in 'proceed' being removed -- wanting to come back to it later.
The time has finally come now.
The patch fixes this -- on resumption, intercepted signals are always
delivered to the thread that had intercepted them.
Another example: if thread 1 stops for a breakpoint, the user switches
to thread 2, and then issues "signal SIGFOO", SIGFOO is actually
delivered to thread 1, not thread 2, because 'proceed' first switches
to thread 1 to step over its breakpoint... If the user deletes the
breakpoint before issuing "signal FOO", then the signal is delivered
to thread 2 (the current thread).
"signal SIGFOO" can be used for two things: inject a signal in the
program while the program/thread had stopped for none, bypassing
"handle nopass"; or changing/suppressing a signal the program had
stopped for. These scenarios are really two faces of the same coin,
and GDB can't really guess what the user is trying to do. GDB might
have intercepted signals in more than one thread even (see the new
signal-command-multiple-signals-pending.exp test). At least in the
inject case, it's obviously clear to me that the user means to deliver
the signal to the currently selected thread, so best is to make the
command's behavior consistent and easy to explain.
Then, if the user is trying to suppress/change a signal the program
had stopped for instead of injecting a new signal, but, the user had
changed threads meanwhile, then she will be surprised that with:
(gdb) continue
Thread 1 stopped for signal SIGFOO.
(gdb) thread 2
(gdb) signal SIGBAR
... GDB actually delivers SIGFOO to thread 1, and SIGBAR to thread 2
(with scheduler-locking off, which is the default, because then
"signal" or any other resumption command resumes all threads).
So the patch makes GDB detect that, and ask for confirmation:
(gdb) thread 1
[Switching to thread 1 (Thread 10979)]
(gdb) signal SIGUSR2
Note:
Thread 3 previously stopped with signal SIGUSR2, User defined signal 2.
Thread 2 previously stopped with signal SIGUSR1, User defined signal 1.
Continuing thread 1 (the current thread) with specified signal will
still deliver the signals noted above to their respective threads.
Continue anyway? (y or n)
All these scenarios are covered by the new tests.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-07-25 Pedro Alves <palves@redhat.com>
* NEWS: Mention signal passing and "signal" command changes.
* gdbthread.h (struct thread_suspend_state) <stop_signal>: Extend
comment.
* breakpoint.c (until_break_command): Adjust clear_proceed_status
call.
* infcall.c (run_inferior_call): Adjust clear_proceed_status call.
* infcmd.c (proceed_thread_callback, continue_1, step_once)
(jump_command): Adjust clear_proceed_status call.
(signal_command): Warn if other thread that are resumed have
signals that will be delivered. Adjust clear_proceed_status call.
(until_next_command, finish_command)
(proceed_after_attach_callback, attach_command_post_wait)
(attach_command): Adjust clear_proceed_status call.
* infrun.c (proceed_after_vfork_done): Likewise.
(proceed_after_attach_callback): Adjust comment.
(clear_proceed_status_thread): Clear stop_signal if not in pass
state.
(clear_proceed_status_callback): Delete.
(clear_proceed_status): New 'step' parameter. Only clear the
proceed status of threads the command being prepared is about to
resume.
(proceed): If passed in an explicit signal, override stop_signal
with it. Don't pass the last stop signal to the thread we're
resuming.
(init_wait_for_inferior): Adjust clear_proceed_status call.
(switch_back_to_stepped_thread): Clear the signal if it should not
be passed.
* infrun.h (clear_proceed_status): New 'step' parameter.
(user_visible_resume_ptid): Add comment.
* linux-nat.c (linux_nat_resume_callback): Don't check whether the
signal is in pass state.
* remote.c (append_pending_thread_resumptions): Likewise.
* mi/mi-main.c (proceed_thread): Adjust clear_proceed_status call.
gdb/doc/
2014-07-25 Pedro Alves <palves@redhat.com>
Eli Zaretskii <eliz@gnu.org>
* gdb.texinfo (Signaling) <signal command>: Explain what happens
with multi-threaded programs.
gdb/testsuite/
2014-07-25 Pedro Alves <palves@redhat.com>
* gdb.threads/signal-command-handle-nopass.c: New file.
* gdb.threads/signal-command-handle-nopass.exp: New file.
* gdb.threads/signal-command-multiple-signals-pending.c: New file.
* gdb.threads/signal-command-multiple-signals-pending.exp: New file.
* gdb.threads/signal-delivered-right-thread.c: New file.
* gdb.threads/signal-delivered-right-thread.exp: New file.
2014-07-25 15:57:31 +00:00
|
|
|
gdb_test "continue" "all_threads_started.*"
|
|
|
|
|
|
|
|
# Using schedlock, let the main thread queue a signal for each
|
|
|
|
# non-main thread.
|
|
|
|
gdb_test_no_output "set scheduler-locking on"
|
|
|
|
|
|
|
|
gdb_test "break all_threads_signalled" "Breakpoint .* at .*$srcfile.*"
|
|
|
|
gdb_test "continue" "all_threads_signalled.*"
|
|
|
|
|
|
|
|
gdb_test "info threads" "\\\* 1\[ \t\]+Thread.*" "thread 1 selected"
|
|
|
|
|
|
|
|
# With schedlock still enabled, let each thread report its
|
|
|
|
# signal.
|
|
|
|
|
|
|
|
gdb_test "thread 3" "Switching to thread 3.*"
|
|
|
|
gdb_test "continue" "Program received signal SIGUSR2.*" "stop with SIGUSR2"
|
|
|
|
gdb_test "thread 2" "Switching to thread 2.*"
|
|
|
|
gdb_test "continue" "Program received signal SIGUSR1.*" "stop with SIGUSR1"
|
|
|
|
|
|
|
|
gdb_test "break handler_sigusr1" "Breakpoint .* at .*$srcfile.*"
|
|
|
|
gdb_test "break handler_sigusr2" "Breakpoint .* at .*$srcfile.*"
|
|
|
|
|
|
|
|
set handler_re "Breakpoint .*, handler_sigusr. \\(sig=.*\\) at .*"
|
|
|
|
|
|
|
|
# Now test the "signal" command with either scheduler locking
|
|
|
|
# enabled or disabled.
|
|
|
|
|
|
|
|
if { $schedlock == "off" } {
|
|
|
|
# With scheduler locking off, switch to the main thread
|
|
|
|
# and issue "signal 0". "signal 0" should then warn that
|
|
|
|
# two threads have signals that will be delivered. When
|
|
|
|
# we let the command proceed, a signal should be
|
|
|
|
# delivered, and thus the corresponding breakpoint in the
|
|
|
|
# signal handler should trigger.
|
|
|
|
|
|
|
|
gdb_test_no_output "set scheduler-locking off"
|
|
|
|
gdb_test "thread 1" "Switching to thread 1.*"
|
|
|
|
|
|
|
|
set queried 0
|
|
|
|
set test "signal command queries"
|
|
|
|
gdb_test_multiple "signal 0" $test {
|
|
|
|
-re "stopped with.*stopped with.*stopped with.*Continue anyway.*y or n. $" {
|
|
|
|
fail "$test (too many threads noted)"
|
|
|
|
set queried 1
|
|
|
|
}
|
|
|
|
-re "stopped with signal SIGUSR.*\r\nContinuing .*still deliver .*Continue anyway.*y or n. $" {
|
|
|
|
pass $test
|
|
|
|
set queried 1
|
|
|
|
}
|
|
|
|
-re "Continue anyway.*y or n. $" {
|
|
|
|
fail "$test (no threads noted)"
|
|
|
|
set queried 1
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
# Continuing should stop in one of the signal handlers.
|
|
|
|
# Which thread runs first is not determinate.
|
|
|
|
if {$queried} {
|
|
|
|
gdb_test "y" "$handler_re" "one signal delivered"
|
|
|
|
}
|
|
|
|
|
|
|
|
# Continuing a second time should stop in the other
|
|
|
|
# handler.
|
|
|
|
with_test_prefix "second signal" {
|
|
|
|
gdb_test "continue" "$handler_re" "signal delivered"
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
# With scheduler locking on, stay with thread 2 selected,
|
|
|
|
# and try to deliver its signal explicitly. The "signal"
|
|
|
|
# command should then warn that one other thread has a
|
|
|
|
# signal that will be delivered. When we let the command
|
|
|
|
# proceed, the current thread's signal should be
|
|
|
|
# delivered, and thus the corresponding breakpoint in the
|
|
|
|
# signal handler should trigger.
|
|
|
|
gdb_test "signal SIGUSR1" \
|
|
|
|
"Breakpoint .*, handler_sigusr1 \\(sig=.*\\) at .*" \
|
|
|
|
"signal command does not query, signal delivered"
|
|
|
|
|
|
|
|
with_test_prefix "second signal" {
|
|
|
|
# The other thread had stopped for a signal too, and
|
|
|
|
# it wasn't resumed yet. Disabling schedlock and
|
|
|
|
# trying "signal 0" from the main thread should warn
|
|
|
|
# again.
|
|
|
|
gdb_test_no_output "set scheduler-locking off"
|
|
|
|
|
|
|
|
set queried 0
|
|
|
|
set test "signal command queries"
|
|
|
|
gdb_test_multiple "signal 0" $test {
|
|
|
|
-re "stopped with.*stopped with.*Continue anyway.*y or n. $" {
|
|
|
|
fail "$test (too many threads noted)"
|
|
|
|
set queried 1
|
|
|
|
}
|
|
|
|
-re "stopped with signal SIGUSR.*\r\nContinuing .*still deliver .*Continue anyway.*y or n. $" {
|
|
|
|
pass $test
|
|
|
|
set queried 1
|
|
|
|
}
|
|
|
|
-re "Continue anyway.*y or n. $" {
|
|
|
|
fail "$test (no threads noted)"
|
|
|
|
set queried 1
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if {$queried} {
|
|
|
|
gdb_test "y" "Breakpoint .*, handler_sigusr2 \\(sig=.*\\) at .*" "signal delivered"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
# Both threads got their signal. Continuing again should
|
|
|
|
# neither intercept nor deliver any other signal.
|
|
|
|
gdb_test "b end" "Breakpoint .* at .*$srcfile.*"
|
|
|
|
gdb_test "continue" "end .*" "no more signals"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
foreach schedlock {"off" "on"} {
|
|
|
|
test $schedlock
|
|
|
|
}
|