From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Cc: Pedro Alves <palves@redhat.com>
Subject: [PATCH] Handle vfork in thread with follow-fork-mode child
Date: Tue, 16 Apr 2019 15:06:00 -0000 [thread overview]
Message-ID: <20190416150652.GA4805@delia> (raw)
Hi,
When debugging the test-case vfork-follow-child.c (which does a vfork in a
thread) with follow-fork-mode child set, we run into this assertion:
...
src/gdb/nat/x86-linux-dregs.c:146: internal-error: \
void x86_linux_update_debug_registers(lwp_info*): \
Assertion `lwp_is_stopped (lwp)' failed.
...
The assert is caused by the following: the event that the vfork child exits,
is handled by handle_vfork_child_exec_or_exit, which calls target_detach to
detach from the vfork parent. During target_detach we call
linux_nat_target::detach, which:
- stops all the threads
- waits for all the threads to be stopped
- detaches all the threads.
However, during the second step we run into this code in stop_wait_callback:
...
/* If this is a vfork parent, bail out, it is not going to report
any SIGSTOP until the vfork is done with. */
if (inf->vfork_child != NULL)
return 0;
...
and we don't wait for the threads to be stopped, which resulting in this
assert in x86_linux_update_debug_registers triggering during the third step:
...
gdb_assert (lwp_is_stopped (lwp));
...
Fix this by resetting the vfork parent's vfork_child field before calling
target_detach in handle_vfork_child_exec_or_exit.
Tested on x86_64-linux, using native and native-gdbserver.
OK for trunk?
Thanks,
- Tom
[gdb] Handle vfork in thread with follow-fork-mode child
gdb/ChangeLog:
2019-04-16 Tom de Vries <tdevries@suse.de>
PR gdb/24454
* infrun.c (handle_vfork_child_exec_or_exit): Reset vfork parent's
avfork_child field before calling target_detach.
gdb/testsuite/ChangeLog:
2019-04-16 Tom de Vries <tdevries@suse.de>
PR gdb/24454
* gdb.threads/vfork-follow-child.c: New test.
* gdb.threads/vfork-follow-child.exp: New file.
---
gdb/infrun.c | 13 ++++++++++++-
gdb/testsuite/gdb.threads/vfork-follow-child.c | 19 +++++++++++++++++++
gdb/testsuite/gdb.threads/vfork-follow-child.exp | 21 +++++++++++++++++++++
3 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/gdb/infrun.c b/gdb/infrun.c
index 37713b24fe..b088138250 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -923,6 +923,7 @@ handle_vfork_child_exec_or_exit (int exec)
struct thread_info *tp;
struct program_space *pspace;
struct address_space *aspace;
+ struct inferior *to_detach;
/* follow-fork child, detach-on-fork on. */
@@ -982,7 +983,17 @@ handle_vfork_child_exec_or_exit (int exec)
}
}
- target_detach (inf->vfork_parent, 0);
+ /* Now that the vfork child has terminated, make sure during detach
+ that we no longer consider the vfork parent to be a vfork parent,
+ but just a regular process that we're detaching from. If not, on
+ linux we would avoid waiting for threads to stop in
+ linux-nat.c:stop_wait_callback, while that was only necessary when
+ the vfork child was still active. */
+ to_detach = inf->vfork_parent;
+ inf->vfork_parent->vfork_child = NULL;
+ inf->vfork_parent = NULL;
+
+ target_detach (to_detach, 0);
/* Put it back. */
inf->pspace = pspace;
diff --git a/gdb/testsuite/gdb.threads/vfork-follow-child.c b/gdb/testsuite/gdb.threads/vfork-follow-child.c
new file mode 100644
index 0000000000..42c76edd01
--- /dev/null
+++ b/gdb/testsuite/gdb.threads/vfork-follow-child.c
@@ -0,0 +1,19 @@
+#include <stdio.h>
+#include <unistd.h>
+#include <pthread.h>
+
+static void *
+f (void *arg)
+{
+ vfork ();
+ return NULL;
+}
+
+int
+main (void)
+{
+ pthread_t tid;
+ pthread_create (&tid, NULL, f, NULL);
+ pthread_join (tid, NULL);
+ return 0;
+}
diff --git a/gdb/testsuite/gdb.threads/vfork-follow-child.exp b/gdb/testsuite/gdb.threads/vfork-follow-child.exp
new file mode 100644
index 0000000000..26896975af
--- /dev/null
+++ b/gdb/testsuite/gdb.threads/vfork-follow-child.exp
@@ -0,0 +1,21 @@
+if { ! [istarget "*-*-linux*"] } {
+ return 0
+}
+
+standard_testfile
+
+if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" \
+ executable {debug}] != "" } {
+ return -1
+}
+
+clean_restart ${binfile}
+
+if ![runto_main] then {
+ fail "can't run to main"
+ return 0
+}
+
+gdb_test "set follow-fork-mode child"
+
+gdb_test "continue" "" "continue"
next reply other threads:[~2019-04-16 15:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-16 15:06 Tom de Vries [this message]
2019-04-17 17:45 ` Pedro Alves
2019-04-18 8:02 ` Tom de Vries
2019-04-18 9:12 ` Pedro Alves
2019-04-18 15:48 ` Tom de Vries
2019-04-18 16:17 ` Pedro Alves
2019-07-23 15:04 ` [8.3 backport] " Tom de Vries
2019-08-13 16:20 ` [PING][8.3 " Tom de Vries
2019-08-15 16:50 ` [8.3 " Pedro Alves
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=20190416150652.GA4805@delia \
--to=tdevries@suse.de \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).