Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Tom de Vries (Code Review)" <gerrit@gnutoolchain-gerrit.osci.io>
To: Pedro Alves <palves@redhat.com>, gdb-patches@sourceware.org
Cc: Mihails Strasuns <mihails.strasuns@intel.com>,
	Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Subject: [review v3] [gdb/threads] Fix hang in stop_all_threads after killing inferior
Date: Thu, 30 Jan 2020 17:52:00 -0000	[thread overview]
Message-ID: <20200130174310.DC7FF20AF7@gnutoolchain-gerrit.osci.io> (raw)
In-Reply-To: <gerrit.1580307037000.Ibe1f29251fe2ff1c1991f041babbe18373c113b1@gnutoolchain-gerrit.osci.io>

Change URL: https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/759
......................................................................

[gdb/threads] Fix hang in stop_all_threads after killing inferior

Consider a two-threaded testcase a.out, sleeping in both its threads:
...
$ gdb -ex r --args a.out
Reading symbols from a.out...
Starting program: /data/gdb_versions/devel/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff77fe700 (LWP 31268)]
...

Typing ^C causes stop_all_threads to be executed, and if an external SIGKILL
(such as caused by killall -9 a.out) arrives at the start of stop_all_threads,
gdb hangs in stop_all_threads after giving this warning:
...
warning: unable to open /proc file '/proc/24938/status'
...

Using "set debug infrun 1" we can see in more detail where we hang:
...
infrun: stop_all_threads
infrun: stop_all_threads, pass=0, iterations=0
infrun:   Thread 0x7ffff7fa6740 (LWP 10264) not executing
infrun:   Thread 0x7ffff77fe700 (LWP 10268) executing, need stop
infrun: target_wait (-1.0.0, status) =
infrun:   10264.10268.0 [Thread 0x7ffff77fe700 (LWP 10268)],
infrun:   status->kind = signalled, signal = GDB_SIGNAL_KILL
infrun: stop_all_threads status->kind = signalled, signal = GDB_SIGNAL_KILL \
  Thread 0x7ffff77fe700 (LWP 10268)
infrun:   Thread 0x7ffff7fa6740 (LWP 10264) not executing
infrun:   Thread 0x7ffff77fe700 (LWP 10268) executing, already stopping
warning: unable to open /proc file '/proc/10264/status'
infrun: target_wait (-1.0.0, status) =
infrun:   -1.0.0 [process -1],
infrun:   status->kind = no-resumed
infrun: infrun_async(0)
infrun: stop_all_threads status->kind = no-resumed process -1
infrun:   Thread 0x7ffff7fa6740 (LWP 10264) not executing
infrun:   Thread 0x7ffff77fe700 (LWP 10268) executing, already stopping
infrun: stop_all_threads status->kind = no-resumed process -1
infrun:   Thread 0x7ffff7fa6740 (LWP 10264) not executing
infrun:   Thread 0x7ffff77fe700 (LWP 10268) executing, already stopping
infrun: stop_all_threads status->kind = no-resumed process -1
infrun:   Thread 0x7ffff7fa6740 (LWP 10264) not executing
infrun:   Thread 0x7ffff77fe700 (LWP 10268) executing, already stopping
<repeat>
......

So, we're hanging in the 'while (1)' loop in stop_all_threads as follows:
- thread t is tested, and both t->executing and t->stop_requested are found
  to be 1 (noted with 'executing, already stopping')
- consequently need_wait is set 1
- consequently wait_one is executed
- wait_one returns a TARGET_WAITKIND_NO_RESUMED event, which is handled by
  continuing at the start of the loop

The loop actually starts with update_thread_list (), but that doesn't seem
to change the state of the threads.

Fix the hang by:
- detecting the first sign of trouble: the TARGET_WAITKIND_SIGNALLED event
  with signal GDB_SIGNAL_KILL,
- making that event pending again,
- making sure the corresponding thread will not set need_wait again
  (by setting t->executing == 0)
- making sure that the corresponding thread keeps t->resumed == 1 in the
  the all_non_exited_threads loop

This results in the ^C being handled without showing the user that the
test-case was killed:
...
^C
Thread 1 received signal SIGINT, Interrupt.
0x00007ffff78c50f0 in nanosleep () from /lib64/libc.so.6
(gdb)
...

But a subsequent continue does show that:
...
(gdb) c
Continuing.

Program terminated with signal SIGKILL, Killed.
The program no longer exists.
(gdb)
....

Build and reg-tested on x86_64-linux.

gdb/ChangeLog:

2020-01-29  Tom de Vries  <tdevries@suse.de>

	PR threads/25478
	* infrun.c (stop_all_threads): Detecting event
	TARGET_WAITKIND_SIGNALLED with signal GDB_SIGNAL_KILL, make event
	pending again, set t->executing to 0 and keep t->resumed set to 1.

Change-Id: Ibe1f29251fe2ff1c1991f041babbe18373c113b1
---
M gdb/infrun.c
1 file changed, 15 insertions(+), 2 deletions(-)



diff --git a/gdb/infrun.c b/gdb/infrun.c
index 22de42c..9587072 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -4749,7 +4749,12 @@
 
 		  /* The thread may be not executing, but still be
 		     resumed with a pending status to process.  */
-		  t->resumed = 0;
+		  if (t->suspend.waitstatus.kind == TARGET_WAITKIND_SIGNALLED
+		      && t->suspend.waitstatus.value.sig == GDB_SIGNAL_KILL
+		      && t->suspend.waitstatus_pending_p)
+		    ;
+		  else
+		    t->resumed = 0;
 		}
 	    }
 
@@ -4772,7 +4777,15 @@
 				  target_pid_to_str (event.ptid).c_str ());
 	    }
 
-	  if (event.ws.kind == TARGET_WAITKIND_NO_RESUMED
+	  if (event.ws.kind == TARGET_WAITKIND_SIGNALLED
+	      && event.ws.value.sig == GDB_SIGNAL_KILL)
+	    {
+	      thread_info *t = find_thread_ptid (event.target, event.ptid);
+	      save_waitstatus (t, &event.ws);
+	      t->resumed = 1;
+	      t->executing = 0;
+	    }
+	  else if (event.ws.kind == TARGET_WAITKIND_NO_RESUMED
 	      || event.ws.kind == TARGET_WAITKIND_THREAD_EXITED
 	      || event.ws.kind == TARGET_WAITKIND_EXITED
 	      || event.ws.kind == TARGET_WAITKIND_SIGNALLED)

-- 
Gerrit-Project: binutils-gdb
Gerrit-Branch: master
Gerrit-Change-Id: Ibe1f29251fe2ff1c1991f041babbe18373c113b1
Gerrit-Change-Number: 759
Gerrit-PatchSet: 3
Gerrit-Owner: Tom de Vries <tdevries@suse.de>
Gerrit-Reviewer: Pedro Alves <palves@redhat.com>
Gerrit-Reviewer: Tom de Vries <tdevries@suse.de>
Gerrit-CC: Mihails Strasuns <mihails.strasuns@intel.com>
Gerrit-CC: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Gerrit-MessageType: newpatchset


  parent reply	other threads:[~2020-01-30 17:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-29 14:11 [review] " Tom de Vries (Code Review)
2020-01-29 15:33 ` Mihails Strasuns (Code Review)
2020-01-29 16:13 ` Tom de Vries (Code Review)
2020-01-29 16:20 ` Tankut Baris Aktemur (Code Review)
2020-01-30 16:30 ` [review v2] " Tom de Vries (Code Review)
2020-01-30 17:36 ` Tankut Baris Aktemur (Code Review)
2020-01-30 17:42 ` Tom de Vries (Code Review)
2020-01-30 17:43 ` Tom de Vries (Code Review)
2020-01-30 17:52 ` Tom de Vries (Code Review) [this message]
2020-02-03 14:30 ` [review v3] " Tankut Baris Aktemur (Code Review)
2020-02-03 15:20 ` Tom de Vries (Code Review)
2020-02-05 19:53 ` [review v4] " Tom de Vries (Code Review)
2020-02-05 19:53 ` Tom de Vries (Code Review)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200130174310.DC7FF20AF7@gnutoolchain-gerrit.osci.io \
    --to=gerrit@gnutoolchain-gerrit.osci.io \
    --cc=gdb-patches@sourceware.org \
    --cc=mihails.strasuns@intel.com \
    --cc=palves@redhat.com \
    --cc=tankut.baris.aktemur@intel.com \
    --cc=tdevries@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox