aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@efficios.com>2021-11-08 16:49:21 -0500
committerSimon Marchi <simon.marchi@polymtl.ca>2021-11-11 13:28:10 -0500
commit4d772ea24dac5d69d913bd0fb748b3070dc8bba6 (patch)
tree2c9c1de2cd360adee95011386ec9bb3e434e0273
parentfdf95218bc08c60ef4528eb67b03643fdd16f036 (diff)
downloadgdb-4d772ea24dac5d69d913bd0fb748b3070dc8bba6.zip
gdb-4d772ea24dac5d69d913bd0fb748b3070dc8bba6.tar.gz
gdb-4d772ea24dac5d69d913bd0fb748b3070dc8bba6.tar.bz2
gdb: fix "set scheduler-locking" thread exit hang
GDB hangs when doing this: - launch inferior with multiple threads - multiple threads hit some breakpoint(s) - one breakpoint hit is presented as a stop, the rest are saved as pending wait statuses - "set scheduler-locking on" - resume the currently selected thread (because of scheduler-locking, it's the only one resumed), let it execute until exit - GDB hangs, not showing the prompt, impossible to interrupt with ^C When the resumed thread exits, we expect the target to return a TARGET_WAITKIND_NO_RESUMED event, and that's what we see: [infrun] fetch_inferior_event: enter [infrun] scoped_disable_commit_resumed: reason=handling event [infrun] random_pending_event_thread: None found. [Thread 0x7ffff7d9c700 (LWP 309357) exited] [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) = [infrun] print_target_wait_results: -1.0.0 [process -1], [infrun] print_target_wait_results: status->kind = no-resumed [infrun] handle_inferior_event: status->kind = no-resumed [infrun] handle_no_resumed: TARGET_WAITKIND_NO_RESUMED (ignoring: found resumed) [infrun] prepare_to_wait: prepare_to_wait [infrun] reset: reason=handling event [infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target native, no resumed threads [infrun] fetch_inferior_event: exit The problem is in handle_no_resumed: we check if some other thread is actually resumed, to see if we should ignore that event (see comments in that function for more info). If this condition is true: (thread->executing () || thread->has_pending_waitstatus ()) ... then we ignore the event. The problem is that there are some non-resumed threads with a pending event, which makes us ignore the event. But these threads are not resumed, so we end up waiting while nothing executes, hence waiting for ever. My first fix was to change the condition to: (thread->executing () || (thread->resumed () && thread->has_pending_waitstatus ())) ... but then it occured to me that we could simply check for: (thread->resumed ()) Since "executing" implies "resumed", checking simply for "resumed" covers threads that are resumed and executing, as well as threads that are resumed with a pending status, which is what we want. Change-Id: Ie796290f8ae7f34c026ca3a8fcef7397414f4780
-rw-r--r--gdb/infrun.c3
-rw-r--r--gdb/testsuite/gdb.threads/schedlock-thread-exit.c46
-rw-r--r--gdb/testsuite/gdb.threads/schedlock-thread-exit.exp42
3 files changed, 89 insertions, 2 deletions
diff --git a/gdb/infrun.c b/gdb/infrun.c
index c634127..95c8bfb 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -5138,8 +5138,7 @@ handle_no_resumed (struct execution_control_state *ecs)
swap_terminal = false;
}
- if (!ignore_event
- && (thread->executing () || thread->has_pending_waitstatus ()))
+ if (!ignore_event && thread->resumed ())
{
/* Either there were no unwaited-for children left in the
target at some point, but there are now, or some target
diff --git a/gdb/testsuite/gdb.threads/schedlock-thread-exit.c b/gdb/testsuite/gdb.threads/schedlock-thread-exit.c
new file mode 100644
index 0000000..ea8a349
--- /dev/null
+++ b/gdb/testsuite/gdb.threads/schedlock-thread-exit.c
@@ -0,0 +1,46 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+ Copyright 2021 Free Software Foundation, Inc.
+
+ 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/>. */
+
+#include <assert.h>
+#include <pthread.h>
+
+static void *
+thread_func (void *p)
+{
+ return NULL;
+}
+
+int
+main (void)
+{
+ const int nthreads = 10;
+ pthread_t threads[nthreads];
+
+ for (int i = 0; i < nthreads; ++i)
+ {
+ int ret = pthread_create (&threads[i], NULL, thread_func, NULL);
+ assert (ret == 0);
+ }
+
+ for (int i = 0; i < nthreads; ++i)
+ {
+ int ret = pthread_join (threads[i], NULL);
+ assert (ret == 0);
+ }
+
+ return 0;
+}
diff --git a/gdb/testsuite/gdb.threads/schedlock-thread-exit.exp b/gdb/testsuite/gdb.threads/schedlock-thread-exit.exp
new file mode 100644
index 0000000..818baa7
--- /dev/null
+++ b/gdb/testsuite/gdb.threads/schedlock-thread-exit.exp
@@ -0,0 +1,42 @@
+# Copyright 2021 Free Software Foundation, Inc.
+
+# 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 GDB handles well a thread exiting with sched-lock on. A buggy GDB
+# would hang, a fixed GDB shows the "No unwaited-for children left" message and
+# shows the prompt.
+#
+# The explanation for the original bug involved some threads with a pending
+# wait status, so we launch multiple threads, which very likely gives us that.
+
+standard_testfile
+
+if { [build_executable "failed to prepare" ${testfile} ${srcfile} {debug pthreads}] } {
+ return
+}
+
+proc do_test { } {
+ clean_restart $::binfile
+
+ # One of the launched threads will report a stop on thread_func. Some
+ # others will also stop on thread_func and have a pending status.
+ if { ![runto "thread_func"] } {
+ return
+ }
+
+ gdb_test_no_output "set scheduler-locking on"
+ gdb_test "continue" "No unwaited-for children left."
+}
+
+do_test