File gdb-testsuite-fix-timeout-in-gdb.threads-main-thread.patch of Package gdb
From e026bf5856f23e9f2bb65b1b01c52d77f106ade8 Mon Sep 17 00:00:00 2001
From: Tom de Vries <tdevries@suse.de>
Date: Tue, 18 Mar 2025 14:17:50 +0100
Subject: [PATCH 5/5] [gdb/testsuite] Fix timeout in
gdb.threads/main-thread-exit-during-detach.exp
With a gdb 15.2 based package and test-case
gdb.threads/main-thread-exit-during-detach.exp, I ran into:
...
(gdb) attach 23068
Attaching to program: main-thread-exit-during-detach, process 23068
[New LWP 23080]
...
0x0000ffffb79aa178 in clock_nanosleep@@GLIBC_2.17 () from /lib64/libc.so.6
(gdb) PASS: $exp: spawn_inferior=true: attach to the inferior
p 1 + 2
$1 = 3
(gdb)
Thread 2 "main-thread-exi" stopped.
0x0000ffffb79aa178 in clock_nanosleep@@GLIBC_2.17 () from /lib64/libc.so.6
FAIL: $exp: spawn_inferior=true: p 1 + 2 (timeout)
...
I managed to reproduce this using two timing hacks.
First, we hack display_gdb_prompt to sleep half a second at the end:
...
printf_unfiltered ("%s", actual_gdb_prompt.c_str ());
gdb_flush (gdb_stdout);
}
+ usleep (500 * 1000);
}
...
to make sure expect has time to:
- parse the output of the attach command up until the prompt,
- issue "PASS: $exp: spawn_inferior=true: attach to the inferior", and
- issue "p 1 + 2"
before gdb issues the "Thread ... stopped." message.
Then we hack proc run_test to wait a while between issuing the print command
and parsing the output:
...
- gdb_test "p 1 + 2" " = 3"
+ set cmd "p 1 + 2"
+ send_gdb "$cmd\n"
+ sleep 1
+ gdb_test "" " = 3" $cmd
...
to make sure that gdb has the time to issue the "Thread ... stopped." message
before the output is parsed.
We could fix this by just using -no-prompt-anchor on the print command, but
there's another issue here.
As explained in the test-case, the setup phase is complete if thread 2 is
stopped:
...
# Setup the inferior. When complete the main thread (#1) will
# still be running (due to non-stop mode), while the worker thread
# (#2) will be stopped.
...
The stated goal of the print statement is:
...
# Attaching to a multi-threaded application in non-stop mode
# can result in thread stops being reported after the prompt
# is displayed.
#
# Send a simple command now just to resync the command prompt.
gdb_test "p 1 + 2" " = 3"
...
so the implicit assumption here seems to be that after this gdb_test, thread 2
is in fact stopped.
However, considering that the reported thread stop is the result of a waitpid
call, which is the result of a SIGSTOP arriving at the thread, I don't think
we can make assumptions about when the thread stop will be reported.
We could fix this by trying to detect the "Thread ... stopped." message, but
doing so will make the test-case much more complex, because it may occur
before and after the attach.
So instead, after the attach, loop doing "info thread 2" until the thread is
no longer reported as running:
...
(gdb) attach 8598^M
Attaching to program: main-thread-exit-during-detach, process 8598^M
[New LWP 8608]^M
...
0x00007f23044f1545 in clock_nanosleep@GLIBC_2.2.5 () from /lib64/libc.so.6^M
(gdb) PASS: $exp: spawn_inferior=true: attach to the inferior
info thread 2^M
Id Target Id Frame ^M
2 Thread 0x7f23043ff6c0 (LWP 8608) "main-thread-exi" (running)^M
(gdb) ^M
Thread 2 "main-thread-exi" stopped.^M
0x00007f23044f1545 in clock_nanosleep@GLIBC_2.2.5 () from /lib64/libc.so.6^M
info thread 2^M
Id Target Id Frame ^M
2 Thread 0x7f23043ff6c0 (LWP 8608) "main-thread-exi" 0x00007f23044f1545 \
in clock_nanosleep@GLIBC_2.2.5 () from /lib64/libc.so.6^M
(gdb) PASS: $exp: spawn_inferior=true: Thread 2 stopped
...
Tested on x86_64-linux.
PR testsuite/32798
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32798
---
.../main-thread-exit-during-detach.exp | 29 +++++++++++++++++--
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/gdb/testsuite/gdb.threads/main-thread-exit-during-detach.exp b/gdb/testsuite/gdb.threads/main-thread-exit-during-detach.exp
index 2a9320a6914..7d6b3845f1e 100644
--- a/gdb/testsuite/gdb.threads/main-thread-exit-during-detach.exp
+++ b/gdb/testsuite/gdb.threads/main-thread-exit-during-detach.exp
@@ -76,10 +76,33 @@ proc run_test { spawn_inferior } {
# Attaching to a multi-threaded application in non-stop mode
# can result in thread stops being reported after the prompt
- # is displayed.
+ # is displayed, so the thread may still be reported as running.
#
- # Send a simple command now just to resync the command prompt.
- gdb_test "p 1 + 2" " = 3"
+ # Iterate until the thread is no longer reported as running.
+ set stopped 0
+ set re_running [string_to_regexp "(running)"]
+ for { set i 0 } { $i < 10 } { incr i } {
+ with_test_prefix $i {
+ gdb_test_multiple "info thread 2" "" -no-prompt-anchor {
+ -re -wrap $re_running.* {
+ }
+ -re -wrap "" {
+ set stopped 1
+ }
+ }
+ }
+ if { $stopped } {
+ break
+ }
+
+ # Back off to let gdb and inferior make progress.
+ sleep 1
+ }
+
+ gdb_assert { $stopped } "Thread 2 stopped"
+ if { ! $stopped } {
+ return -1
+ }
# Set thread 1 (the current thread) running again.
gdb_test "continue&"
--
2.43.0
