Re: [PATCH] Ignore the last EXIT_THREAD_DEBUG_EVENT on Windows

> From: Tom Tromey <[email protected]>
> Cc: Tom Tromey <[email protected]>,  [email protected]
> Date: Fri, 21 Aug 2026 12:18:05 -0600
> 
> >>>>> "Eli" == Eli Zaretskii <[email protected]> writes:
> 
> Eli> How can we know that a given thread is a "final" one, when Windows is
> Eli> known to start its own threads for the program being debugged?
> 
> We track when threads are created and destroyed, and only apply this
> behavior when there is a single thread remaining.

Is there no possibility whatsoever that another thread will be created
while we handle the termination of what we consider to be "the last
thread"?  Even though GDB supports scheduler-locking and non-stop mode
on Windows?

Also, doesn't EXIT_PROCESS_DEBUG_EVENT provide to us data about the
process (like its exit code) that EXIT_THREAD_DEBUG_EVENT does not?

> Eli> Are you sure there are no such threads left running after all the
> Eli> threads known to GDB exit, and cause this issue?
> 
> Yes, extracted from the log in the bug, here are all the thread and
> process events:
> 
> [windows events] get_windows_debug_event: kernel event for pid=1604 tid=0x89c code=CREATE_PROCESS_DEBUG_EVENT
>   [windows events] get_windows_debug_event: kernel event for pid=1604 tid=0xc20 code=CREATE_THREAD_DEBUG_EVENT
>   [windows events] get_windows_debug_event: kernel event for pid=1604 tid=0xc20 code=EXIT_THREAD_DEBUG_EVENT
>   [windows events] get_windows_debug_event: kernel event for pid=1604 tid=0x89c code=EXIT_THREAD_DEBUG_EVENT

Did you succeed in capturing EXIT_THREAD_DEBUG_EVENT after receiving
EXIT_PROCESS_DEBUG_EVENT this way?

> >> 1. It only happened under load, I was never able to reproduce it by
> >> running a single test case.
> 
> Eli> What do you mean by "load" in this case? what kind of load?
> 
> If I run one test case in isolation, it never fails.  However if I run
> the whole test suite, which defaults to running as many tests as there
> are CPUs, I do see some failures.  Frequently -- but not always -- the
> same tests fail.

Then this could be a problem due to effect of previous/other tests,
which run before or in parallel with this test.  In which case I'm not
sure we should install this change.  As you say, the OS should handle
this issue for us, and the OS always knows better which thread is the
last one.  I worry that we could introduce a possibility of
regressions if we install this workaround for a problem for which we
have only insufficient understanding.