public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@palves.net>
To: gdb-patches@sourceware.org
Subject: [PATCH 03/11] Fix gdb.threads/current-lwp-dead.exp race
Date: Thu,  3 Mar 2022 14:40:12 +0000	[thread overview]
Message-ID: <20220303144020.3601082-4-pedro@palves.net> (raw)
In-Reply-To: <20220303144020.3601082-1-pedro@palves.net>

If we make GDB report the process EXIT event for the leader thread, as
will be done in a latter patch of this series, then
gdb.threads/current-lwp-dead.exp starts failing:

 (gdb) break fn_return
 Breakpoint 2 at 0x5555555551b5: file /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/current-lwp-dead.c, line 45.
 (gdb) continue
 Continuing.
 [New LWP 2138466]
 [Inferior 1 (process 2138459) exited normally]
 (gdb) FAIL: gdb.threads/current-lwp-dead.exp: continue to breakpoint: fn_return (the program exited)

The inferior exit reported is actually correct.  The main thread has
indeed exited, and that's the thread that has the right exit code to
report to the user, as that's the exit code that is reported to the
program's parent.  In this case, GDB managed to collect the exit code
for the leader thread before reaping the other thread, because in
reality, the testcase isn't creating standard threads, it is using raw
clone, and the new clones are put in their own thread group.

Fix it by making the main "thread" not exit until the scenario we're
exercising plays out.  Also, run the program to completion for
completeness.

The original program really wanted the leader thread to exit before
the fn_return function was reached -- it was important that the
current thread as pointed by inferior_ptid was gone when infrun got
the breakpoint event.  I've tweaked the testcase to ensure that that
condition is still held, though it is no longer the main thread that
exits.  This required a bit of synchronization between the threads,
which required using CLONE_VM unconditionally.  The #ifdef guards were
added as a fix for
https://sourceware.org/bugzilla/show_bug.cgi?id=11214, though I don't
think they were necessary because the program is not using TLS.  If it
turns out they were necessary, we can link the testcase with "-z now"
instead, which was mentioned as an alternative workaround in that
Bugzilla.

Change-Id: I7be2f0da4c2fe8f80a60bdde5e6c623d8bd5a0aa
---
 gdb/testsuite/gdb.threads/current-lwp-dead.c  | 101 ++++++++++++------
 .../gdb.threads/current-lwp-dead.exp          |  23 +++-
 2 files changed, 87 insertions(+), 37 deletions(-)

diff --git a/gdb/testsuite/gdb.threads/current-lwp-dead.c b/gdb/testsuite/gdb.threads/current-lwp-dead.c
index 76babc42ce8..ceb3ae47a4d 100644
--- a/gdb/testsuite/gdb.threads/current-lwp-dead.c
+++ b/gdb/testsuite/gdb.threads/current-lwp-dead.c
@@ -15,6 +15,18 @@
    You should have received a copy of the GNU General Public License
    along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
+
+   The original issue we're trying to test is described in this
+   thread:
+
+     https://sourceware.org/legacy-ml/gdb-patches/2009-06/msg00802.html
+
+   The NEW_THREAD_EVENT code the comments below refer to no longer
+   exists in GDB, so the following comments are kept for historical
+   reasons, and to guide future updates to the testcase.
+
+   ---
+
    Do not use threads as we need to exploit a bug in LWP code masked by the
    threads code otherwise.
 
@@ -29,60 +41,81 @@
 #include <assert.h>
 #include <unistd.h>
 #include <stdlib.h>
-
-#include <features.h>
-#ifdef __UCLIBC__
-#if !(defined(__UCLIBC_HAS_MMU__) || defined(__ARCH_HAS_MMU__))
-#define HAS_NOMMU
-#endif
-#endif
+#include <sys/types.h>
+#include <sys/wait.h>
 
 #define STACK_SIZE 0x1000
 
-static int
-fn_return (void *unused)
-{
-  return 0;	/* at-fn_return */
-}
+/* True if the 'fn_return' thread has been reached at the point after
+   its parent is already gone.  */
+volatile int fn_return_reached = 0;
+
+/* True if the 'fn' thread has exited.  */
+volatile int fn_exited = 0;
+
+/* Wrapper around clone.  */
 
 static int
-fn (void *unused)
+do_clone (int (*fn)(void *))
 {
-  int i;
   unsigned char *stack;
   int new_pid;
 
-  i = sleep (1);
-  assert (i == 0);
-
   stack = malloc (STACK_SIZE);
   assert (stack != NULL);
 
-  new_pid = clone (fn_return, stack + STACK_SIZE, CLONE_FILES
-#if defined(__UCLIBC__) && defined(HAS_NOMMU)
-		   | CLONE_VM
-#endif /* defined(__UCLIBC__) && defined(HAS_NOMMU) */
-		   , NULL, NULL, NULL, NULL);
+  new_pid = clone (fn, stack + STACK_SIZE, CLONE_FILES | CLONE_VM,
+		   NULL, NULL, NULL, NULL);
   assert (new_pid > 0);
 
+  return new_pid;
+}
+
+static int
+fn_return (void *unused)
+{
+  /* Wait until our direct parent exits.  We want the breakpoint set a
+     couple lines below to hit with the previously-selected thread
+     gone.  */
+  while (!fn_exited)
+    usleep (1);
+
+  fn_return_reached = 1; /* at-fn_return */
+  return 0;
+}
+
+static int
+fn (void *unused)
+{
+  do_clone (fn_return);
   return 0;
 }
 
 int
 main (int argc, char **argv)
 {
-  unsigned char *stack;
-  int new_pid;
-
-  stack = malloc (STACK_SIZE);
-  assert (stack != NULL);
-
-  new_pid = clone (fn, stack + STACK_SIZE, CLONE_FILES
-#if defined(__UCLIBC__) && defined(HAS_NOMMU)
-		   | CLONE_VM
-#endif /* defined(__UCLIBC__) && defined(HAS_NOMMU) */
-		   , NULL, NULL, NULL, NULL);
-  assert (new_pid > 0);
+  int new_pid, status, ret;
+
+  new_pid = do_clone (fn);
+
+  /* Note the clone call above didn't use CLONE_THREAD, so it actually
+     put the new child in a new thread group.  However, the new clone
+     is still reported with PTRACE_EVENT_CLONE to GDB, since we didn't
+     use CLONE_VFORK (results in PTRACE_EVENT_VFORK) nor set the
+     termination signal to SIGCHLD (results in PTRACE_EVENT_FORK), so
+     GDB thinks of it as a new thread of the same inferior.  It's a
+     bit of an odd setup, but it's not important for what we're
+     testing, and, it let's us conveniently use waitpid to wait for
+     the child, which you can't with CLONE_THREAD.  */
+  ret = waitpid (new_pid, &status, __WALL);
+  assert (ret == new_pid);
+  assert (WIFEXITED (status) && WEXITSTATUS (status) == 0);
+
+  fn_exited = 1;
+
+  /* Don't exit before the breakpoint at fn_return triggers.  */
+  while (!fn_return_reached)
+    usleep (1);
 
   return 0;
 }
diff --git a/gdb/testsuite/gdb.threads/current-lwp-dead.exp b/gdb/testsuite/gdb.threads/current-lwp-dead.exp
index b69fdbb5988..6728dbe87ab 100644
--- a/gdb/testsuite/gdb.threads/current-lwp-dead.exp
+++ b/gdb/testsuite/gdb.threads/current-lwp-dead.exp
@@ -15,8 +15,14 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
-# Please email any bugs, comments, and/or additions to this file to:
-# bug-gdb@gnu.org
+# Regression test for issue originally described here:
+#
+#  https://sourceware.org/legacy-ml/gdb-patches/2009-06/msg00802.html
+#
+# The relevant code has since been removed from GDB, but it doesn't
+# hurt to keep the testcase.
+
+standard_testfile
 
 # This only works with on Linux targets.
 if ![istarget *-*-linux*] then {
@@ -31,5 +37,16 @@ if {[runto_main] <= 0} {
     return -1
 }
 
-gdb_breakpoint "fn_return"
+# Run to "fn" so that thread 2 is made current.
+gdb_breakpoint "fn"
+gdb_continue_to_breakpoint "fn" ".*do_clone.*"
+
+# Run to thread 3, at a point where thread 2 is gone.
+set line [gdb_get_line_number "at-fn_return"]
+gdb_breakpoint $line
 gdb_continue_to_breakpoint "fn_return" ".*at-fn_return.*"
+
+# Confirm thread 2 is really gone.
+gdb_test "info threads 2" "No threads match '2'\\."
+
+gdb_continue_to_end "" continue 1
-- 
2.26.2


  parent reply	other threads:[~2022-03-03 14:40 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-03 14:40 [PATCH 00/11] Linux: Fix issues around thread group leader exits Pedro Alves
2022-03-03 14:40 ` [PATCH 01/11] Fix gdbserver/linux target_waitstatus logging assert Pedro Alves
2022-03-03 14:40 ` [PATCH 02/11] Fix gdb.threads/clone-new-thread-event.exp race Pedro Alves
2022-03-03 14:40 ` Pedro Alves [this message]
2022-03-03 14:40 ` [PATCH 04/11] gdb: Reorganize linux_nat_filter_event Pedro Alves
2022-03-03 14:40 ` [PATCH 05/11] gdbserver: Reorganize linux_process_target::filter_event Pedro Alves
2022-03-03 14:40 ` [PATCH 06/11] gdbserver: Reindent check_zombie_leaders Pedro Alves
2022-03-03 14:40 ` [PATCH 07/11] Re-add zombie leader on exit, gdb/linux Pedro Alves
2022-03-07 20:08   ` Simon Marchi
2022-03-07 20:27     ` Pedro Alves
2022-03-07 20:31       ` Simon Marchi
2022-03-09 14:37         ` Pedro Alves
2022-03-03 14:40 ` [PATCH 08/11] Re-add zombie leader on exit, gdbserver/linux Pedro Alves
2022-03-03 14:40 ` [PATCH 09/11] Ensure EXIT is last event, gdb/linux Pedro Alves
2022-03-07 20:24   ` Simon Marchi
2022-03-09  0:21     ` Lancelot SIX
2022-03-09 14:45       ` Pedro Alves
2022-03-09 22:29         ` Lancelot SIX
2022-03-10 11:46           ` Pedro Alves
2022-03-03 14:40 ` [PATCH 10/11] Ensure EXIT is last event, gdbserver/linux Pedro Alves
2022-03-03 14:40 ` [PATCH 11/11] Process exit status is leader exit status testcase Pedro Alves
2023-06-22 11:28   ` Ilya Leoshkevich
2023-06-22 13:07     ` Tom de Vries

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=20220303144020.3601082-4-pedro@palves.net \
    --to=pedro@palves.net \
    --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).