For step-over-syscall.exp, we have normally: ... $ for n in $(seq 1 10); do ./test.sh; done 2>&1 | egrep "expected passes|unresolved testcases" # of expected passes 95 # of expected passes 95 # of expected passes 95 # of expected passes 95 # of expected passes 95 # of expected passes 95 # of expected passes 95 # of expected passes 95 # of expected passes 95 # of expected passes 95 ... But when run in conjunction with: ... $ stress -c $(($(cat /proc/cpuinfo | grep -c "^processor") + 1)) ... we get: ... $ for n in $(seq 1 10); do ./test.sh; done 2>&1 | egrep "expected passes|unresolved testcases" # of expected passes 90 # of expected passes 90 # of expected passes 90 # of expected passes 95 # of expected passes 90 # of expected passes 90 # of expected passes 90 # of expected passes 90 # of expected passes 95 # of expected passes 90 ... We run into: ... FAIL: gdb.base/step-over-syscall.exp: clone: displaced=off: single step over clone ... More specifically: ... (gdb) PASS: gdb.base/step-over-syscall.exp: clone: displaced=off: continue to syscall insn clone set displaced-stepping off^M (gdb) PASS: gdb.base/step-over-syscall.exp: clone: displaced=off: set displaced-stepping off stepi^M [New LWP 21290]^M Couldn't get registers: No such process.^M (gdb) FAIL: gdb.base/step-over-syscall.exp: clone: displaced=off: single step over clone ...
I installed openSUSE Tumbleweed in a VM, with 1 virtual CPU and execution cap set to 75%. In this setting, this reproduces every time.
I see this too.
Hmm, let's see if https://sourceware.org/pipermail/gdb-patches/2022-July/190708.html fixes this.
(In reply to Tom de Vries from comment #3) > Hmm, let's see if > https://sourceware.org/pipermail/gdb-patches/2022-July/190708.html fixes > this. It does, as noted in https://sourceware.org/pipermail/gdb-patches/2022-October/192287.html .