[PATCH 2/2] [gdb/testsuite] Add KFAIL in gdb.threads/fork-plus-threads.exp

[Simon Marchi]

On 2021-10-26 19:37, Tom de Vries wrote:
> When running test-case gdb.threads/fork-and-threads.exp on a VM with openSUSE
> Tumbleweed, with the VM bound to 1 cpu with 75% execution cap, I get:
> ...
> (gdb) info inferiors^M
>   Num  Description       Connection           Executable        ^M
> * 1    <null>                                 fork-plus-threads ^M
>   11   <null>                                 fork-plus-threads ^M
> (gdb) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: \
>   only inferior 1 left
> ...
> 
> The test checks that all removable inferiors are indeed removed from the
> inferior list after exit, and evidently this didn't happen for inferior 11
> (which is added by fork rather than a user command, and therefore removable).
> 
> I've investigated why that is that case, and it's because its refcount didn't
> drop to 0.
> 
> This seems like a bug to me, so add a KFAIL for thi
Hmm, I attached to GDB after this failure, and inferior 11's refcount
was 0.

My guess is that in the working case, all inferiors are pruned when
prune_inferiors is called, which is called by normal_stop, which is
called by fetch_inferior_event when the thread_fsm (for the continue
command) completes.

And in the failing case, the thread_fsm completes when inferior 1
exits, that is before inferior 11 exits.  So prune_inferior leaves
inferior 11 there.  When inferior 11 finally exits (immediatly after,
when we process the next event), no thread_fsm complete, so normal_stop
isn't called, so prune_inferiors isn't called.

This particular problem could maybe be solved by having some call to
prune_inferiors somehwere else, so that it's called after inferior 11
exit.

If we implement the suggestion I sent on patch 1 (about the order of
events), that additional call to prune_inferiors probably wouldn't be
necessary in this case.  But it might still be needed in other corner
cases.

Simon