Re: [PATCH] Cygwin/testsuite: Avoid infinite hang

[Kevin Buettner <kevinb@redhat.com>]

On Fri, 12 Apr 2024 16:21:21 +0100
Pedro Alves <pedro@palves.net> wrote:

> On Cygwin, the gdb.base/fork-no-detach-follow-child-dlopen.exp
> testcase hits a sequence of cascading FAILs:
> 
>  (gdb) run
>  Starting program: ..../gdb.base/fork-no-detach-follow-child-dlopen/fork-no-detach-follow-child-dlopen
>  [New Thread 12672.0x318c]
>  [New Thread 12672.0x2844]
>  [New Thread 12672.0x714]
>  FAIL: gdb.base/fork-no-detach-follow-child-dlopen.exp: runto: run to add (timeout)
>  frame
>  FAIL: gdb.base/fork-no-detach-follow-child-dlopen.exp: frame (timeout)
>  list
>  FAIL: gdb.base/fork-no-detach-follow-child-dlopen.exp: list (timeout)
> 
> And the test program never makes progress.
> 
> ... and at this point, Cygwin is completely stuck.  I can't run any
> other Cygwin program.
> 
> However, if we run the test program outside DejaGnu, we see something
> different:
> 
>   (gdb) b add
>   Function "add" not defined.
>   Make breakpoint pending on future shared library load? (y or [n]) y
>   Breakpoint 1 (add) pending.
>   (gdb) r
>   Starting program: ..../gdb.base/fork-no-detach-follow-child-dlopen/fork-no-detach-follow-child-dlopen
>   [New Thread 10968.0x834]
>   [New Thread 10968.0x29a4]
>   [New Thread 10968.0x16b8]
>   [New Thread 10968.0xf9c]
>   [Switching to Thread 10968.0x16b8]
> 
>   Thread 4 "sig" hit Breakpoint 1.2, pending_signals::add (pack=..., this=0x7ffa1e748a40 <sigq>) at /usr/src/debug/cygwin-3.4.9-1/winsup/cygwin/sigproc.cc:1304
>   1304      se = sigs + pack.si.si_signo;
>   (gdb)
> 
> Ah, the test wanted to run to a global "add" function, but managed to
> stop at an internal Cygwin method called "add".  And stopping there
> deadlocks everything Cygwin in the system.  (I believe some
> cygwin1.dll mechanisms use cross-process synchronization or
> communication, we're probably blocking something like that.)
> 
> Fix this by using "break -q".  The tests FAIL because we don't support
> follow-fork for Cygwin, but at least we no longer deadlock the
> machine.

Thanks for the detailed explanation!

Approved-by: Kevin Buettner <kevinb@redhat.com>