From: "Pedro Alves (Code Review)" <gerrit@gnutoolchain-gerrit.osci.io>
To: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>,
gdb-patches@sourceware.org
Cc: Luis Machado <luis.machado@linaro.org>
Subject: [review v2] infrun: handle already-exited threads when attempting to stop
Date: Fri, 06 Dec 2019 16:19:00 -0000 [thread overview]
Message-ID: <20191206161922.9E42F2816F@gnutoolchain-gerrit.osci.io> (raw)
In-Reply-To: <gerrit.1571405222000.I7cec98f40283773b79255d998511da434e9cd408@gnutoolchain-gerrit.osci.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
next prev parent reply other threads:[~2019-12-06 16:19 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-18 13:27 [review] infrun: mark an exited thread non-executing " Tankut Baris Aktemur (Code Review)
2019-11-04 8:36 ` Tankut Baris Aktemur (Code Review)
2019-11-04 10:23 ` [review v2] infrun: handle already-exited threads " Tankut Baris Aktemur (Code Review)
2019-12-04 12:02 ` Tankut Baris Aktemur (Code Review)
2019-12-05 19:26 ` Pedro Alves (Code Review)
2019-12-06 16:19 ` Pedro Alves (Code Review) [this message]
2019-12-06 17:41 ` Tankut Baris Aktemur (Code Review)
2019-12-09 15:09 ` Tankut Baris Aktemur (Code Review)
2020-01-08 15:57 ` Tankut Baris Aktemur (Code Review)
2020-01-29 17:54 ` Tom de Vries (Code Review)
2020-01-30 9:10 ` Tom de Vries (Code Review)
2020-01-30 13:58 ` Tom de Vries (Code Review)
2020-01-30 16:41 ` Tankut Baris Aktemur (Code Review)
2020-01-30 21:06 ` Tom de Vries (Code Review)
2020-02-03 15:13 ` Tom de Vries (Code Review)
2020-02-03 16:02 ` Tankut Baris Aktemur (Code Review)
2020-02-03 16:27 ` Tom de Vries (Code Review)
2020-02-04 9:06 ` Tankut Baris Aktemur (Code Review)
2020-02-05 13:19 ` [review v3] " Tankut Baris Aktemur (Code Review)
2020-02-05 13:24 ` Tankut Baris Aktemur (Code Review)
2020-02-05 22:59 ` Tom de Vries (Code Review)
2020-02-07 12:11 ` Tankut Baris Aktemur (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=20191206161922.9E42F2816F@gnutoolchain-gerrit.osci.io \
--to=gerrit@gnutoolchain-gerrit.osci.io \
--cc=gdb-patches@sourceware.org \
--cc=gnutoolchain-gerrit@osci.io \
--cc=luis.machado@linaro.org \
--cc=tankut.baris.aktemur@intel.com \
/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