Re: [PATCH] Windows gdb: Don't abort get_windows_debug_event with no threads

[Eli Zaretskii <eliz@gnu.org>]

> From: Hannes Domani <ssbssa@yahoo.de>
> Date: Wed, 26 Aug 2026 20:20:37 +0200
> 
> 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.

Thanks.

Tom, it sounds like this is the root cause of the problem you tried to
fix in https://sourceware.org/pipermail/gdb-patches/2026-August/229659.html,
no?