Re: [PATCH] Ignore the last EXIT_THREAD_DEBUG_EVENT on Windows

[Tom Tromey <tromey@adacore.com>]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> 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.

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

>> 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.

Tom