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

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

[Hannes Domani]

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
---
 gdb/windows-nat.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
index 4cd301d4959..2fa15ada27a 100644
--- a/gdb/windows-nat.c
+++ b/gdb/windows-nat.c
@@ -1367,15 +1367,20 @@ windows_nat_target::thread_events (bool enable)
   m_report_thread_events = enable;
 }
 
-/* True if there is any resumed thread.  */
+/* True if there is any resumed thread, or no thread at all.  */
 
 bool
 windows_nat_target::any_resumed_thread ()
 {
+  bool has_thread = false;
   for (thread_info &thread : all_non_exited_threads (this))
-    if (thread.internal_state () == THREAD_INT_RUNNING)
-      return true;
-  return false;
+    {
+      has_thread = true;
+      if (thread.internal_state () == THREAD_INT_RUNNING)
+	return true;
+    }
+  DEBUG_EVENTS ("any_resumed_thread: has_thread=%d", has_thread);
+  return !has_thread;
 }
 
 /* Called for both EXIT_THREAD_DEBUG_EVENT and
-- 
2.54.0

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

[Eli Zaretskii]

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

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

[Tom Tromey]

>>>>> "Hannes" == Hannes Domani <ssbssa@yahoo.de> writes:

Hannes> This fixes it by changing any_resumed_thread to return true if there is
Hannes> no thread at all.

Hannes> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34195

Thanks, this is ok.
Please apply it to gdb-18 as well.

Tom

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

[Hannes Domani]

 Am Donnerstag, 27. August 2026 um 17:25:28 MESZ hat Tom Tromey <tom@tromey.com> Folgendes geschrieben:

> >>>>> "Hannes" == Hannes Domani <ssbssa@yahoo.de> writes:
> 
> Hannes> This fixes it by changing any_resumed_thread to return true if there is
> Hannes> no thread at all.
> 
> Hannes> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34195
> 
> Thanks, this is ok.
> Please apply it to gdb-18 as well.

Thanks.
I've pushed it to master and gdb-18-branch after adding this:
Approved-By: Tom Tromey <tom@tromey.com>


Hannes