public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: gdb-patches@sourceware.org
Subject: [PATCH] gdb: iterate only on vfork parent threads in handle_vfork_child_exec_or_exit
Date: Thu,  5 Aug 2021 12:21:35 -0400	[thread overview]
Message-ID: <20210805162135.729540-1-simon.marchi@polymtl.ca> (raw)

I spotted what I think is a buglet in proceed_after_vfork_done.  After a
vfork child exits or execs, we resume all the threads of the parent.  To
do so, we iterate on all threads using iterate_over_threads with the
proceed_after_vfork_done callback.  Each thread is resumed if the
following condition is true:

    if (thread->ptid.pid () == pid
	&& thread->state == THREAD_RUNNING
	&& !thread->executing
	&& !thread->stop_requested
	&& thread->stop_signal () == GDB_SIGNAL_0)

where `pid` is the pid of the vfork parent.  This is not multi-target
aware: since it only filters on pid, if there is an inferior with the
same pid in another target, we could end up resuming a thread of that
other inferior.  The chances of the stars aligning for this to happen
are tiny, but still.

Fix that by iterating only on the vfork parent's threads, instead of on
all threads.  This is more efficient, as we iterate on just the required
threads (inferiors have their own thread list), and we can drop the pid
check.  The resulting code is also more straightforward in my opinion,
so it's a win-win.

Change-Id: I14647da72e2bf65592e82fbe6efb77a413a4be3a
---
 gdb/infrun.c | 29 ++++++++++++-----------------
 1 file changed, 12 insertions(+), 17 deletions(-)

diff --git a/gdb/infrun.c b/gdb/infrun.c
index 8870f82b9cc3..5ee650fa4645 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -855,17 +855,13 @@ follow_inferior_reset_breakpoints (void)
   insert_breakpoints ();
 }
 
-/* The child has exited or execed: resume threads of the parent the
-   user wanted to be executing.  */
+/* The child has exited or execed: resume THREAD, a thread of the parent,
+   if it was meant to be executing.  */
 
-static int
-proceed_after_vfork_done (struct thread_info *thread,
-			  void *arg)
+static void
+proceed_after_vfork_done (thread_info *thread)
 {
-  int pid = * (int *) arg;
-
-  if (thread->ptid.pid () == pid
-      && thread->state == THREAD_RUNNING
+  if (thread->state == THREAD_RUNNING
       && !thread->executing
       && !thread->stop_requested
       && thread->stop_signal () == GDB_SIGNAL_0)
@@ -877,8 +873,6 @@ proceed_after_vfork_done (struct thread_info *thread,
       clear_proceed_status (0);
       proceed ((CORE_ADDR) -1, GDB_SIGNAL_DEFAULT);
     }
-
-  return 0;
 }
 
 /* Called whenever we notice an exec or exit event, to handle
@@ -891,7 +885,7 @@ handle_vfork_child_exec_or_exit (int exec)
 
   if (inf->vfork_parent)
     {
-      int resume_parent = -1;
+      inferior *resume_parent = nullptr;
 
       /* This exec or exit marks the end of the shared memory region
 	 between the parent and the child.  Break the bonds.  */
@@ -969,7 +963,7 @@ handle_vfork_child_exec_or_exit (int exec)
 	  inf->removable = 1;
 	  set_current_program_space (inf->pspace);
 
-	  resume_parent = vfork_parent->pid;
+	  resume_parent = vfork_parent;
 	}
       else
 	{
@@ -995,21 +989,22 @@ handle_vfork_child_exec_or_exit (int exec)
 	  inf->symfile_flags = SYMFILE_NO_READ;
 	  clone_program_space (inf->pspace, vfork_parent->pspace);
 
-	  resume_parent = vfork_parent->pid;
+	  resume_parent = vfork_parent;
 	}
 
       gdb_assert (current_program_space == inf->pspace);
 
-      if (non_stop && resume_parent != -1)
+      if (non_stop && resume_parent != nullptr)
 	{
 	  /* If the user wanted the parent to be running, let it go
 	     free now.  */
 	  scoped_restore_current_thread restore_thread;
 
 	  infrun_debug_printf ("resuming vfork parent process %d",
-			       resume_parent);
+			       resume_parent->pid);
 
-	  iterate_over_threads (proceed_after_vfork_done, &resume_parent);
+	  for (thread_info *thread : resume_parent->threads ())
+	    proceed_after_vfork_done (thread);
 	}
     }
 }
-- 
2.32.0


             reply	other threads:[~2021-08-05 16:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-05 16:21 Simon Marchi [this message]
2021-08-05 17:08 ` John Baldwin
2021-08-10 19:52   ` Simon Marchi
2021-08-10 19:40 ` 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=20210805162135.729540-1-simon.marchi@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=gdb-patches@sourceware.org \
    /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).