[Bug tdep/34195] Windows tests report "No unwaited-for children left."

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

--- Comment #11 from Hannes Domani <ssbssa at sourceware dot org> ---
I reproduced this today, and as Tom said, it only happens when the machine is
doing heavy load.

The heavy load I got by building something with make -j10, and with gdb I let a
simple "return 0;" C-application continuously run like this:
set pagination off
set debugevents
set logging debugredirect on
set logging file events.txt
set logging enabled
set $i=0
while $i<1000
run
set $i=$i+1
end

Seeing that a problem happened was simple, because gdb then crashed at the
following 'run'.

The interesting logs:
[windows events] get_windows_debug_event: kernel event for pid=24300 tid=0x56c0
code=CREATE_PROCESS_DEBUG_EVENT
[windows events] get_windows_debug_event: kernel event for pid=24300 tid=0x4a14
code=CREATE_THREAD_DEBUG_EVENT
[windows events] get_windows_debug_event: kernel event for pid=24300 tid=0x56c0
code=EXIT_THREAD_DEBUG_EVENT
[windows events] get_windows_debug_event: kernel event for pid=24300 tid=0x4a14
code=EXIT_THREAD_DEBUG_EVENT
[windows events] wait: get_windows_debug_event returned [0.0.0 : status->kind =
SPURIOUS, fake=0]
[windows events] wait: get_windows_debug_event returned [-1.0.0 : status->kind
= NO_RESUMED, fake=1]
No unwaited-for children left.

So my next step was doing the same with the commit before non-stop support
(edeff39baffb07b68e8790980dbee20965123621).
This showed me that the situation with no thread happened then as well, but was
immediately followed by a CREATE_THREAD_DEBUG_EVENT:
[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
[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

With the non-stop commit we no longer get to the CREATE_THREAD_DEBUG_EVENT
event
because of this code in windows_nat_target::get_windows_debug_event of
windows-nat.c:
  /* 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;
    }

It's also the reason why I got that status->kind = NO_RESUMED in my bad log
above.
Commenting it out makes this situation work for me again, but presumably would
introduce another problem.

Maybe, in addition to checking if there is any resumed thread, it should also
check if there is any thread at all before returning?
This also worked for me:
--- a/gdb/windows-nat.c
+++ b/gdb/windows-nat.c
@@ -1299,10 +1299,15 @@ windows_nat_target::thread_events (bool enable)
 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

But I don't really understand what that ourstatus->set_no_resumed () is for, so
take this with a grain of salt.

-- 
You are receiving this mail because:
You are on the CC list for the bug.