Re: [PATCH] Ignore the last EXIT_THREAD_DEBUG_EVENT on Windows

[Eli Zaretskii <eliz@gnu.org>]

> From: Tom Tromey <tromey@adacore.com>
> Cc: Tom Tromey <tromey@adacore.com>
> Date: Fri, 21 Aug 2026 10:18:28 -0600
> 
> The Windows non-stop series caused some regressions in the internal
> AdaCore test suite.  I filed this as PR tdep/34195.  I finally found
> some time to look into the problem, and this patch is the result.
> 
> The symptom of the problem is that some fairly ordinary tests -- like
> a test to simply run a do-nothing program to completion -- would fail
> because gdb would print "No unwaited-for children left."
> 
> I bisected the problem to commit ae2f226d ("Windows gdb: Add non-stop
> support").
> 
> Instrumenting the test suite to enable logging showed something
> strange: in the failing case, we'd see and EXIT_THREAD_DEBUG_EVENT for
> each thread, but never an EXIT_PROCESS_DEBUG_EVENT.
> 
> And, since gdb didn't see or handle an EXIT_PROCESS_DEBUG_EVENT, the
> process would remain live -- one of the internal AdaCore tests checks
> this (via some "ps" equivalent), causing a separate failure.
> 
> After a lot of experimentation I came up with this patch.  It changes
> gdb to ignore the final EXIT_THREAD_DEBUG_EVENT, waiting instead for
> an EXIT_PROCESS_DEBUG_EVENT to do the cleanup.  This fixed the
> regressions in my testing.

How can we know that a given thread is a "final" one, when Windows is
known to start its own threads for the program being debugged?  Are
you sure there are no such threads left running after all the threads
known to GDB exit, and cause this issue?

> 1. It only happened under load, I was never able to reproduce it by
>    running a single test case.

What do you mean by "load" in this case? what kind of load?

Thanks.