This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[PATCH] linux_nat.c: Mark new thread running even if momentarily pausing
- From: Pedro Alves <palves at redhat dot com>
- To: gdb-patches at sourceware dot org
- Date: Thu, 26 Mar 2015 13:32:26 +0000
- Subject: [PATCH] linux_nat.c: Mark new thread running even if momentarily pausing
- Authentication-results: sourceware.org; auth=none
My all-stop-on-top-of-non-stop series manages to trip on a bug in the
linux-nat.c backend while running the testsuite. If a thread is
discovered while threads are being momentarily paused (without the
core's intervention), the thread ends up stuck in THREAD_STOPPED
state, even though from the user's perspective, the thread is running
even while it is paused.
>From inspection, in the current sources, this can happen if we call
stop_and_resume_callback, though there's no way to test that with
current Linux kernels.
(While trying to come up with test to exercise this, I stumbled on:
https://sourceware.org/ml/gdb-patches/2015-03/msg00850.html
... which does include a non-trivial test, so I think I can still
claim I come out net positive. :-) )
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
2015-03-26 Pedro Alves <palves@redhat.com>
* linux-nat.c (linux_handle_extended_wait): Always call set_running.
---
gdb/linux-nat.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/gdb/linux-nat.c b/gdb/linux-nat.c
index 0376299..04707dc 100644
--- a/gdb/linux-nat.c
+++ b/gdb/linux-nat.c
@@ -2109,9 +2109,12 @@ linux_handle_extended_wait (struct lwp_info *lp, int status,
add_thread (new_lp->ptid);
}
+ /* Even if we're stopping the thread for some reason
+ internal to this module, from the user/frontend's
+ perspective, this new thread is running. */
+ set_running (new_lp->ptid, 1);
if (!stopping)
{
- set_running (new_lp->ptid, 1);
set_executing (new_lp->ptid, 1);
/* thread_db_attach_lwp -> lin_lwp_attach_lwp forced
resume_stop. */
--
1.9.3