public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
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"

             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).