[review v2] infrun: handle already-exited threads when attempting to stop

Pedro Alves (Code Review)
2019-12-06T16:19:29Z

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