[Bug tdep/34195] Windows tests report "No unwaited-for children left."
"cvs-commit at gcc dot gnu.org via Gdb-prs" <[email protected]>
| Newsgroups | gmane.comp.gdb.bugs.discuss |
|---|---|
| Message-ID | <[email protected]/bugzilla/> |
https://sourceware.org/bugzilla/show_bug.cgi?id=34195 --- Comment #15 from Sourceware Commits <cvs-commit at gcc dot gnu.org> --- The gdb-18-branch branch has been updated by Hannes Domani <[email protected]>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=524f668fa5aede1acbf8125ca677941a34951ebd commit 524f668fa5aede1acbf8125ca677941a34951ebd Author: Hannes Domani <[email protected]> Date: Wed Aug 26 19:35:52 2026 +0200 Windows gdb: Don't abort get_windows_debug_event with no threads When a machine is under heavy load, windows sometimes provides the debug events in a weird order: [windows events] get_windows_debug_event: kernel event for pid=22208 tid=0x6df0 code=CREATE_PROCESS_DEBUG_EVENT [windows events] get_windows_debug_event: kernel event for pid=22208 tid=0xe74 code=CREATE_THREAD_DEBUG_EVENT [windows events] get_windows_debug_event: kernel event for pid=22208 tid=0xe74 code=EXIT_THREAD_DEBUG_EVENT [windows events] get_windows_debug_event: kernel event for pid=22208 tid=0x6df0 code=EXIT_THREAD_DEBUG_EVENT At this point the process has seemingly no threads, even though for the last thread there should be EXIT_PROCESS_DEBUG_EVENT instead of EXIT_THREAD_DEBUG_EVENT. But the next event shows that a new thread was created, which then finally got EXIT_PROCESS_DEBUG_EVENT: [windows events] get_windows_debug_event: kernel event for pid=22208 tid=0x5a7c code=CREATE_THREAD_DEBUG_EVENT [windows events] get_windows_debug_event: kernel event for pid=22208 tid=0x5a7c code=EXIT_PROCESS_DEBUG_EVENT Since the introduction of non-stop support, gdb fails with this error at the point of no threads: No unwaited-for children left. It's because it added this check which prevents getting the next debug event: /* If there are no resumed threads left, bail. */ if (windows_process->windows_initialization_done && !any_resumed_thread ()) { ourstatus->set_no_resumed (); return minus_one_ptid; } This fixes it by changing any_resumed_thread to return true if there is no thread at all. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34195 Approved-By: Tom Tromey <[email protected]> -- You are receiving this mail because: You are on the CC list for the bug.