diff options
author | Tom de Vries <tdevries@suse.de> | 2025-03-27 13:18:57 +0100 |
---|---|---|
committer | Tom de Vries <tdevries@suse.de> | 2025-03-27 13:18:57 +0100 |
commit | 4bf692ec70394f1157371f21092eeb1c3e9181bb (patch) | |
tree | 2123e5b9dc2a4e13e3678f41fe02d2fffb0dbf55 /gdb/python | |
parent | fdb44fced279a672f6bfe3f79ff9432a26e01ecc (diff) | |
download | binutils-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/python')
0 files changed, 0 insertions, 0 deletions