Re: [PATCH] Ignore the last EXIT_THREAD_DEBUG_EVENT on Windows
Tom Tromey <[email protected]>
| Newsgroups | gmane.comp.gdb.patches |
|---|---|
| Message-ID | <[email protected]> |
>>>>> "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. 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