Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Subject: [PATCH] [gdb/testsuite] Extend gdb.base/kill-during-detach.exp
Date: Tue,  9 Jan 2024 17:56:20 +0100	[thread overview]
Message-ID: <20240109165620.18066-1-tdevries@suse.de> (raw)

I ran into the following FAIL:
...
(gdb) python kill_and_detach()^M
Traceback (most recent call last):^M
  File "<string>", line 1, in <module>^M
  File "<string>", line 7, in kill_and_detach^M
gdb.error: Selected thread is running.^M
Error while executing Python code.^M
(gdb) FAIL: gdb.base/kill-during-detach.exp: exit_p=true: checkpoint_p=true: \
  python kill_and_detach()
...

The FAIL happens as follows:
- gdb is debugging a process A
- a checkpoint is created, in other words, fork is called in the inferior,
  after which we have:
  - checkpoint 0 (the fork parent, process A), and
  - checkpoint 1 (the fork child, process B).
- during checkpoint creation, lseek is called in the inferior (process A) for
  all file descriptors, and it returns != -1 for at least one file descriptor.
- the process A continues in the background
- gdb detaches, from process A
- gdb switches to process B, in other words, it restarts checkpoint 1
- while restarting checkpoint 1, gdb tries to call lseek in the inferior
  (process B), but this fails because gdb incorrectly thinks that inferior B
  is running.

This happens because linux_nat_switch_fork patches the pid of process B into
the current inferior and current thread which where originally representing
process A.  So, because process A was running in the background, the
thread_info fields executing and resumed are set accordingly, but they are not
correct for process B.

There's a line in fork_load_infrun_state that fixes up the thread_info field
stop_pc, so fix this by adding similar fixups for the executing and resumed
fields alongside.

The FAIL did not always reproduce, so extend the test-case to reliably
trigger this scenario.

Tested on x86_64-linux.

PR gdb/31203
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31203
---
 gdb/linux-fork.c                              |  2 ++
 gdb/testsuite/gdb.base/kill-during-detach.c   | 26 +++++++++++++++++++
 gdb/testsuite/gdb.base/kill-during-detach.exp | 16 +++++++++++-
 3 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/gdb/linux-fork.c b/gdb/linux-fork.c
index 1430ff89fa7..ac4277e3962 100644
--- a/gdb/linux-fork.c
+++ b/gdb/linux-fork.c
@@ -227,6 +227,8 @@ fork_load_infrun_state (struct fork_info *fp)
 
   inferior_thread ()->set_stop_pc
     (regcache_read_pc (get_thread_regcache (inferior_thread ())));
+  inferior_thread ()->set_executing (false);
+  inferior_thread ()->set_resumed (false);
   nullify_last_target_wait_ptid ();
 
   /* Now restore the file positions of open file descriptors.  */
diff --git a/gdb/testsuite/gdb.base/kill-during-detach.c b/gdb/testsuite/gdb.base/kill-during-detach.c
index 2d9cca91e2f..9567eab1e2e 100644
--- a/gdb/testsuite/gdb.base/kill-during-detach.c
+++ b/gdb/testsuite/gdb.base/kill-during-detach.c
@@ -16,14 +16,40 @@
    along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
 
 #include <unistd.h>
+#include <stdio.h>
+#include <assert.h>
 
 volatile int dont_exit_just_yet = 1;
 
+#define XSTR(s) STR(s)
+#define STR(s) #s
+
+volatile int with_checkpoint = 0;
+
 int
 main ()
 {
   alarm (300);
 
+  if (with_checkpoint)
+    {
+      /* We open a file and move file pos from 0 to 1.  We set the checkpoint
+	 when pos is 0, and restart it when pos is 1.  This makes sure that
+	 restarting the checkpoint excercises calling lseek in the
+	 inferior. */
+
+      /* Open a file. */
+      const char *filename = XSTR (BINFILE);
+      FILE *fp = fopen (filename, "r");
+      assert (fp != NULL);
+
+      volatile int checkpoint_here = 0; /* Checkpoint here.  */
+
+      /* Move file pos from 0 to 1.  */
+      int res = fseek (fp, 1, SEEK_SET);
+      assert (res == 0);
+    }
+
   /* Spin until GDB releases us.  */
   while (dont_exit_just_yet)
     usleep (100000);
diff --git a/gdb/testsuite/gdb.base/kill-during-detach.exp b/gdb/testsuite/gdb.base/kill-during-detach.exp
index 26028d5fc34..a5b0127f4b7 100644
--- a/gdb/testsuite/gdb.base/kill-during-detach.exp
+++ b/gdb/testsuite/gdb.base/kill-during-detach.exp
@@ -39,10 +39,16 @@ if { [istarget "*-*-linux*"] && [target_info gdb_protocol] == ""} {
     set has_checkpoint false
 }
 
-if {[build_executable "failed to prepare" $testfile $srcfile] == -1} {
+set flags {}
+lappend flags debug
+lappend flags additional_flags=-DBINFILE=$binfile
+
+if {[build_executable "failed to prepare" $testfile $srcfile $flags] == -1} {
     return -1
 }
 
+set checkpoint_line [gdb_get_line_number "Checkpoint here"]
+
 # Start an inferior, which blocks in a spin loop.  Setup a Python
 # function that performs an action based on EXIT_P that will cause the
 # inferior to exit, and then, within the same Python function, ask GDB
@@ -78,6 +84,14 @@ proc run_test { exit_p checkpoint_p } {
     }
 
     if { $checkpoint_p } {
+	# Active checkpoint-specific code in $srcfile.
+	gdb_test_no_output "set var with_checkpoint=1"
+
+	# Run to line where we want to set the checkpoint.
+	gdb_breakpoint "$::srcfile:$::checkpoint_line"
+	gdb_continue_to_breakpoint "checkpoint line"
+
+	# Set the checkpoint.
 	gdb_test "checkpoint" \
 	    "checkpoint 1: fork returned pid $::decimal\\."
     }

base-commit: d006ec41c448d9f4a84df50391e87cbf0aa8c152
-- 
2.35.3


             reply	other threads:[~2024-01-09 16:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-09 16:56 Tom de Vries [this message]
2024-01-10 19:16 ` Kevin Buettner

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=20240109165620.18066-1-tdevries@suse.de \
    --to=tdevries@suse.de \
    --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