aboutsummaryrefslogtreecommitdiff
path: root/gdb
diff options
context:
space:
mode:
authorTom de Vries <tdevries@suse.de>2025-03-27 13:18:57 +0100
committerTom de Vries <tdevries@suse.de>2025-03-27 13:18:57 +0100
commit4bf692ec70394f1157371f21092eeb1c3e9181bb (patch)
tree2123e5b9dc2a4e13e3678f41fe02d2fffb0dbf55 /gdb
parentfdb44fced279a672f6bfe3f79ff9432a26e01ecc (diff)
downloadbinutils-4bf692ec70394f1157371f21092eeb1c3e9181bb.zip
binutils-4bf692ec70394f1157371f21092eeb1c3e9181bb.tar.gz
binutils-4bf692ec70394f1157371f21092eeb1c3e9181bb.tar.bz2
[gdb/testsuite] Fix gdb.threads/access-mem-running-thread-exit.exp
In OBS (Open Build Service), with a 15.2 based gdb package, occasionally I run into: ... (gdb) inferior 2 [Switching to inferior 2 [process 31372] (access-mem-running-thread-exit)] [Switching to thread 2.1 (Thread 0xf7db9700 (LWP 31372))](running) (gdb) print global_var = 555 $1 = 555 (gdb) print global_var $2 = 556 (gdb) FAIL: $exp: all-stop: access mem \ (print global_var after writing, inf=2, iter=1) ... I managed to reproduce this on current trunk using a reproducer patch (posted in the PR). The problem is due to commit 31c21e2c13d ("[gdb/testsuite] Fix gdb.threads/access-mem-running-thread-exit.exp with clang"), which introduced an increment of global_var at the start of main. This created a race between: - gdb modifying global_var, and - the inferior modifying global_var. Fix this by: - adding a new empty function setup_done, - adding a call to setup_done after the increment of global_var, and - rather than running to main, running to setup_done. Tested on x86_64-linux. PR testsuite/32822 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32822
Diffstat (limited to 'gdb')
-rw-r--r--gdb/testsuite/gdb.threads/access-mem-running-thread-exit.c7
-rw-r--r--gdb/testsuite/gdb.threads/access-mem-running-thread-exit.exp10
2 files changed, 12 insertions, 5 deletions
diff --git a/gdb/testsuite/gdb.threads/access-mem-running-thread-exit.c b/gdb/testsuite/gdb.threads/access-mem-running-thread-exit.c
index af05b13..e22bf12 100644
--- a/gdb/testsuite/gdb.threads/access-mem-running-thread-exit.c
+++ b/gdb/testsuite/gdb.threads/access-mem-running-thread-exit.c
@@ -97,6 +97,11 @@ thread_fn (void *arg)
return NULL;
}
+static void
+setup_done (void)
+{
+}
+
int
main (void)
{
@@ -104,6 +109,8 @@ main (void)
global_var++;
+ setup_done ();
+
for (i = 0; i < 4; i++)
{
struct thread_arg *p;
diff --git a/gdb/testsuite/gdb.threads/access-mem-running-thread-exit.exp b/gdb/testsuite/gdb.threads/access-mem-running-thread-exit.exp
index 784f17f..42222c0 100644
--- a/gdb/testsuite/gdb.threads/access-mem-running-thread-exit.exp
+++ b/gdb/testsuite/gdb.threads/access-mem-running-thread-exit.exp
@@ -54,7 +54,7 @@ proc test { non_stop } {
clean_restart ${binfile}
}
- if ![runto_main] {
+ if ![runto setup_done] {
return -1
}
@@ -76,7 +76,7 @@ proc test { non_stop } {
# Start the second inferior.
with_test_prefix "second inferior" {
# With stub targets that do reload on run, if we let the new
- # inferior share inferior 1's connection, runto_main would
+ # inferior share inferior 1's connection, runto would
# fail because GDB is already connected to something, like
# e.g. with --target_board=native-gdbserver:
#
@@ -86,10 +86,10 @@ proc test { non_stop } {
# Already connected to a remote target. Disconnect? (y or n)
#
# Instead, start the inferior with no connection, and let
- # gdb_load/runto_main spawn a new remote connection/gdbserver.
+ # gdb_load/runto spawn a new remote connection/gdbserver.
#
# OTOH, with extended-remote, we must let the new inferior
- # reuse the current connection, so that runto_main below can
+ # reuse the current connection, so that runto below can
# issue the "run" command, and have the inferior run on the
# remote target. If we forced no connection, then "run" would
# either fail if "set auto-connect-native-target" is on, like
@@ -108,7 +108,7 @@ proc test { non_stop } {
gdb_load $binfile
- if ![runto_main] {
+ if ![runto setup_done] {
return -1
}
}