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

[Pedro Alves <pedro@palves.net>]

On 2025-06-10 08:13, Tom de Vries wrote:
> On 6/6/25 15:11, Pedro Alves wrote:

>> I've long suspected that this is actually some deadlock bug in Cygwin somewhere around
>> closing stdin/stdout, and I still suspect so.  But I can't discard it being a GDB bug.
>>
> 
> If cygwin is problematic, I'm happy to ignore it and use one of the other setups.
> 
> I've tried msys2, but also there I run into trouble ( https://sourceware.org/bugzilla/show_bug.cgi?id=33072 ) and I get even less far than on cygwin: starting gdb is a problem because it produces some control characters that the testsuite doesn't expect, and I can't debug it because the gdb executable is missing debug info.

That's because when you say "msys2", you're really saying that you tried to test MinGW GDB with MSYS2 DejaGnu.

Thing is, MSYS2 _is_ Cygwin.  Or rather, it's a Cygwin fork with a few extra patches that make is easier
to bridge Cygwin programs and MinGW programs.  It's kind of like if they were different Linux distros, but of Cygwin.

For my Windows non-stop work, it's important that I test Cygwin GDB, because the Windows native target has
special support for some extra Cygwin-only features, like Cygwin signals.

> 
>> I didn't use to have this issue maybe a year ago, then I stopped working on Windows for a
>> few months, and when I got back at it, I started seeing the issue.  It's like some Cygwin
>> update, or Windows update caused the issue.
> 
> I also wonder whether it's easy to introduce regressions in gdb by testing mingw but not cygwin.

We need to test both.  For the Windows target backend (windows-nat.c and friends), most of the code is
common between Cygwin and MinGW, but there are a few important differences.  For example, the support
for Cygwin signals just doesn't exist on MinGW, because, well, it's a Cygwin thing.  And then, 
the common code outside windows-nat.c takes different paths (POSIX vs native Windows APIs) in
important areas, like Ctrl-C handling, terminal I/O and event loop, to name a few.

I'm very much interested in testing mingw GDB too, BTW.  That is actually my end goal.

> 
> Anyway, my windows/cygwin setup is fresh.  I bought a windows laptop this spring with windows 11 home, and installed cygwin on it.

FWIW, I run Windows on a VM (on Linux/KVM/libvirt).  Simon also recently installed Cygwin and didn't see
the same issue I see.  I'll need to try recreating my setup from scratch, maybe this issue just goes away...

> 
>> The hang is like other hangs I've observed before, it's around closing GDB to restart it
>> for more tests, and the patch at:
>>
>> https://sourceware.org/pipermail/gdb-patches/2025-May/217949.html
>>
>> still helps with it for me.  With that one on top of yours, and with
>> gdb.base/branch-to-self.exp, I get:
>>
>>   WARNING: closing gdb failed with: child process exited abnormally
>>
>> (the same as what I get without your patch) and the testcase moves on and
>> finishes properly (though a couple tests fail with timeout, as they do for you.)
>>
> 
> I've not seen that failure mode sofar, but thanks for the fix, that looks useful.
> 
>> If I look at the task manager while doing a full testsuite run, I see a bunch of leftover
>> gdb.exe processes and their children still running, because dejagnu fails to properly
>> close gdb.exe.
> 
> I also see other cases of processes left behind.  I've filed this (https://sourceware.org/bugzilla/show_bug.cgi?id=33061 ) for one of those.
> 
> I've also got a patch submitted here ( https://patchwork.sourceware.org/project/gdb/patch/20250217163619.8662-3-tdevries@suse.de/ ) for another case.
> 

Thanks, I hadn't seen it.

Pedro Alves