[Bug gdb/29762] New: FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: access mem (print global_var after writing again, inf=2, iter=1)

["simark at simark dot ca" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29762

            Bug ID: 29762
           Summary: FAIL: gdb.threads/access-mem-running-thread-exit.exp:
                    non-stop: access mem (print global_var after writing
                    again, inf=2, iter=1)
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: simark at simark dot ca
  Target Milestone: ---

I get this failure very rarely on my CI.  I managed to reproduce it on my dev
machine by running:

$ while taskset -c 1,19 make check
TESTS="gdb.threads/access-mem-running-thread-exit.exp"
RUNTESTFLAGS="--target_board=native-extended-gdbserver";do done

It takes a few runs, maybe a few minutes, but it eventually fails.

I think running

$ stress -n $(nproc)

at the same time helped, but maybe it was just an illusion.

Here's an instance of the failure:

(gdb) print global_var = 555^M
$1 = 555^M
(gdb) print global_var^M
$2 = 555^M
(gdb) print global_var = 333^M
$3 = 333^M
(gdb) print global_var^M
$4 = 123^M
(gdb) FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: access
mem (print global_var after writing again, inf=2, iter=1)

In another case it looks like this:

(gdb) print global_var = 555^M
$1 = 555^M
(gdb) print global_var^M
$2 = 123^M
(gdb) FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: access
mem (print global_var after writing, inf=2, iter=1)

I don't know if the taskset is a red herring, but I never got a failure by
running it without the taskset, or by running with taskset on a single core.

Interestingly, all the failures I got were always on iter=1.

I don't really know what kind of racy problem it could be in GDB.  It sounds
like a "write memory on one core, get migrated to another CPU, then read the
old value on another core" kind of problem.

-- 
You are receiving this mail because:
You are on the CC list for the bug.