With test.sh setup to run test-case gdb.threads/process-dies-while-detaching.exp, and running in conjunction with stress -c 5, we get: ... $ for n in $(seq 1 50); do ./test.sh 2>&1 | tee TESTLOG.$n; cp gdb.log gdb.$n.log; cp gdb.sum gdb.$n.sum; done | grep "expected passes" # of expected passes 66 # of expected passes 65 # of expected passes 66 # of expected passes 66 # of expected passes 66 # of expected passes 66 ... In gdb.2.sum, we find this fail: ... FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint: continue ... In more detail (in gdb.2.log): ... (gdb) PASS: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint: continue to breakpoint: _exit continue^M Continuing.^M Couldn't get registers: No such process.^M (gdb) FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint: continue ...
Created attachment 12254 [details] gdb.1.log
Created attachment 12255 [details] gdb.2.log
Note: there is an identical FAIL line in PR21321 - "AddressSanitizer: heap-use-after-free in gdbserver/linux-low.c", but there the fail is with -fsanitize=address and --target_board='native-gdbserver'.
I usually build gdb with -O0. I just did a build with -O2, and this FAIL (or, a FAIL like this in the same test) becomes much more likely: ... $ for n in $(seq 1 10); do ./test.sh 2>&1 | tee TESTLOG.$n; cp gdb.log gdb.$n.log; cp gdb.sum gdb.$n.sum; done | grep "expected passes" # of expected passes 65 # of expected passes 65 # of expected passes 64 # of expected passes 64 # of expected passes 63 # of expected passes 64 # of expected passes 65 # of expected passes 64 # of expected passes 65 # of expected passes 65 $ grep ^FAIL: gdb.[1-9].sum gdb.10.sum gdb.1.sum:FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: killed outside: continue gdb.2.sum:FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: detach: continue gdb.3.sum:FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: detach: continue gdb.3.sum:FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: killed outside: continue gdb.4.sum:FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint: continue gdb.4.sum:FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: killed outside: continue gdb.5.sum:FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: detach: continue gdb.5.sum:FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint: continue gdb.5.sum:FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: killed outside: continue gdb.6.sum:FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: detach: continue gdb.6.sum:FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint: continue gdb.7.sum:FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint: continue gdb.8.sum:FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint: continue gdb.8.sum:FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: killed outside: continue gdb.9.sum:FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint: continue gdb.10.sum:FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint: continue ...
I installed openSUSE Tumbleweed in a VM, with 1 virtual CPU and execution cap set to 75%. In this setting, this reproduces every time.