Re: [PATCH] [gdb/tdep] Don't call WaitForSingleObject with INFINITE arg

Pedro Alves
2025-06-05T16:16:38Z

On 2025-06-05 16:03, Tom de Vries wrote:
> I decided to try to build and test gdb on Windows.
>
> I found a page on the wiki ( https://sourceware.org/gdb/wiki/BuildingOnWindows
> ) suggesting three ways of building gdb:
> - MinGW,
> - MinGW on Cygwin, and
> - Cygwin.
>
> I picked Cygwin, because I've used it before (though not recently).
>
> I managed to install Cygwin and sufficient packages to build gdb and start the
> testsuite.

Cool!

FYI, I cross build from Linux using this: https://github.com/palves/cygwin-cross
and then test from Cygwin, by:

- smb mounting the sources from linux
- configuring only the testsuite, not the whole gdb (src/gdb/testsuite/configure)
- copying over gdb.exe to the Windows box (via rsync)
- pointing at the copied gdb with make check GDB=.../gdb.exe

I do this because building on Linux is so much faster.

>
> However, testsuite progress ground to a halt at gdb.base/branch-to-self.exp.
> [ AFAICT, similar problems reported here [1]. ]

The testsuite fails to kill gdb all the time for me, it may well be the same.
I'll give it a try after you've merged it.

Ecstatic that you found this!

>
> I managed to reproduce this hang by running just the test-case.
>
> I attempted to kill the hanging processes by:
> - first killing the inferior process, using the cygwin "kill -9" command, and
> - then killing the gdb process, likewise.
>
> But the gdb process remained, and I had to point-and-click my way through task
> manager to actually kill the gdb process.
>
> I investigated this by attaching to the hanging gdb process. Looking at the
> main thread, I saw it was stopped in a call to WaitForSingleObject, with
> the dwMilliseconds parameter set to INFINITE.
>
> The backtrace in more detail:
> ...
> (gdb) bt
> #0 0x00007fff196fc044 in ntdll!ZwWaitForSingleObject () from
> /cygdrive/c/windows/SYSTEM32/ntdll.dll
> #1 0x00007fff16bbcdcf in WaitForSingleObjectEx () from
> /cygdrive/c/windows/System32/KERNELBASE.dll
> #2 0x0000000100998065 in wait_for_single (handle=0x1b8, howlong=4294967295) at
> gdb/windows-nat.c:435
> #3 0x0000000100999aa7 in
> windows_nat_target::do_synchronously(gdb::function_view<bool ()>)
> (this=this@entry=0xa001c6fe0, func=...) at gdb/windows-nat.c:487
> #4 0x000000010099a7fb in windows_nat_target::wait_for_debug_event_main_thread
> (event=<optimized out>, this=0xa001c6fe0)
> at gdb/../gdbsupport/function-view.h:296
> #5 windows_nat_target::kill (this=0xa001c6fe0) at gdb/windows-nat.c:2917
> #6 0x00000001008f2f86 in target_kill () at gdb/target.c:901
> #7 0x000000010091fc46 in kill_or_detach (from_tty=0, inf=0xa000577d0)
> at gdb/top.c:1658
> #8 quit_force (exit_arg=<optimized out>, from_tty=from_tty@entry=0)
> at gdb/top.c:1759
> #9 0x00000001004f9ea8 in quit_command (args=args@entry=0x0,
> from_tty=from_tty@entry=0) at gdb/cli/cli-cmds.c:483
> #10 0x000000010091c6d0 in quit_cover () at gdb/top.c:295
> #11 0x00000001005e3d8a in async_disconnect (arg=<optimized out>)
> at gdb/event-top.c:1496
> #12 0x0000000100499c45 in invoke_async_signal_handlers ()
> at gdb/async-event.c:233
> #13 0x0000000100eb23d6 in gdb_do_one_event (mstimeout=mstimeout@entry=-1)
> at gdbsupport/event-loop.cc:198
> #14 0x00000001006df94a in interp::do_one_event (mstimeout=-1,
> this=<optimized out>) at gdb/interps.h:87
> #15 start_event_loop () at gdb/main.c:402
> #16 captured_command_loop () at gdb/main.c:466
> #17 0x00000001006e2865 in captured_main (data=0x7ffffcba0) at gdb/main.c:1346
> #18 gdb_main (args=args@entry=0x7ffffcc10) at gdb/main.c:1365
> #19 0x0000000100f98c70 in main (argc=10, argv=0xa000129f0) at gdb/gdb.c:38
> ...
>
> In the docs [2], I read that using an INFINITE argument to WaitForSingleObject
> might cause a system deadlock.

Wow, unbelievable. Thanks a lot for going all the way and finding this.

>
> This prompted me to try this simple change in wait_for_single:
> ...
> while (true)
> {
> - DWORD r = WaitForSingleObject (handle, howlong);
> + DWORD r = WaitForSingleObject (handle,
> + howlong == INFINITE ? 100 : howlong);
> + if (howlong == INFINITE && r == WAIT_TIMEOUT)
> + continue;
> ...
> with the timeout of 0.1 second estimated to be:
> - small enough for gdb to feel reactive, and
> - big enough not to consume too much cpu cycles with looping.
>
> And indeed, the test-case, while still failing, now finishes in ~50 seconds.
>
> While there may be an underlying bug that triggers this behaviour, the failure
> mode is so severe that I consider it a bug in itself.
>

Yeah. The documentation talks about the the case of the code spawning windows, which
I don't think we do. But still. I've seen so many weird things on Windows...
It's just one more.

> Fix this by avoiding calling WaitForSingleObject with INFINITE argument.

Approved-By: Pedro Alves <pedro@palves.net>