This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[review v2] infrun: handle already-exited threads when attempting to stop
- From: "Pedro Alves (Code Review)" <gerrit at gnutoolchain-gerrit dot osci dot io>
- To: Tankut Baris Aktemur <tankut dot baris dot aktemur at intel dot com>, gdb-patches at sourceware dot org
- Cc: Luis Machado <luis dot machado at linaro dot org>
- Date: Fri, 6 Dec 2019 11:19:22 -0500
- Subject: [review v2] infrun: handle already-exited threads when attempting to stop
- Auto-submitted: auto-generated
- References: <gerrit.1571405222000.I7cec98f40283773b79255d998511da434e9cd408@gnutoolchain-gerrit.osci.io>
- Reply-to: gnutoolchain-gerrit at osci dot io
Pedro Alves has posted comments on this change.
Change URL: https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/133
......................................................................
Patch Set 2:
(1 comment)
| --- gdb/infrun.c
| +++ gdb/infrun.c
| @@ -4494,7 +4509,19 @@ stop_all_threads (void)
| + if (ws.kind == TARGET_WAITKIND_THREAD_EXITED)
| + delete_thread (t);
| + else
| + {
| + /* TARGET_WAITKIND_EXITED or
| + TARGET_WAITKIND_SIGNALLED. */
| + /* Need to restore the context because
| + handle_inferior_exit switches it. */
| + scoped_restore_current_pspace_and_thread restore;
| + handle_inferior_exit (event_ptid, ws);
PS2, Line 4518:
Sorry, but this doesn't look right.
We're inside stop_all_threads, processing some other event, and a
process exit event for one of the processes we're trying to stop comes
along, and this processes it right away. Once the stop_all_threads
dance is done, we go back to handling the original event, and possibly
reporting a stop to the user. Meanwhile, whatever state that was set
by handle_inferior_exit, like e.g. $_exitcode, is lost, or now
incorrect for the reported stop. We also never present a stop on the
CLI for that "spurious" process exit. Here:
(gdb)
continue
Continuing.
Executing on build: kill -9 29412 29417 (timeout = 300)
spawn -ignore SIGHUP kill -9 29412 29417
Program terminated with signal SIGKILL, Killed.
The program no longer exists.
<<<<<<<<<<< no user-visible stop / prompt here. <<<<<<<<<<<<<<<
Program terminated with signal SIGKILL, Killed.
The program no longer exists.
(gdb) PASS: gdb.multi/multi-kill.exp: iteration 1: back to gdb prompt
The fix for this I think must be around leaving the
TARGET_WAITKIND_EXITED/TARGET_WAITKIND_SIGNALLED
event pending, so that it is processed later when we're out of the
stop_all_threads loop and back to
dequeuing the next event.
gdb/linux-nat.c also has its own "stop all threads temporarily" logic,
and that does that -- leaves process exits pending. See wait_lwp:
/* If this is the leader exiting, it means the whole
process is gone. Store the status to report to the
core. Store it in lp->waitstatus, because lp->status
would be ambiguous (W_EXITCODE(0,0) == 0). */
store_waitstatus (&lp->waitstatus, status);
return 0;
| + }
| + }
| }
| else
| {
| thread_info *t = find_thread_ptid (event_ptid);
| if (t == NULL)
| t = add_thread (event_ptid);
|
--
Gerrit-Project: binutils-gdb
Gerrit-Branch: master
Gerrit-Change-Id: I7cec98f40283773b79255d998511da434e9cd408
Gerrit-Change-Number: 133
Gerrit-PatchSet: 2
Gerrit-Owner: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Gerrit-Reviewer: Luis Machado <luis.machado@linaro.org>
Gerrit-Reviewer: Pedro Alves <palves@redhat.com>
Gerrit-Reviewer: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Gerrit-Comment-Date: Fri, 06 Dec 2019 16:19:22 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment