Re: [PATCH 3/3] Windows: Fix run/attach hang after bad run/attach

[Hannes Domani <ssbssa@yahoo.de>]

 Am Montag, 12. Februar 2024 um 21:02:54 MEZ hat Pedro Alves <pedro@palves.net> Folgendes geschrieben:

> On Cygwin, gdb.base/attach.exp exposes that a attach after a
> previously failed attach hangs:
>
> (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: attach to digits-starting nonsense is prohibited
> attach 0
> Can't attach to process 0 (error 2: The system cannot find the file specified.)
> (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: attach to nonexistent process is prohibited
> attach 10644
> FAIL: gdb.base/attach.exp: do_attach_failure_tests: first attach (timeout)
>
> The problem is that windows_nat_target::attach always returns success
> even if the attach fails.  When we return success, the helper thread
> begins waiting for events (which will never come), and thus the next
> attach deadlocks on the do_synchronously call within
> windows_nat_target::attach.
>
> "run" has the same problem, which is exposed by the new
> gdb.base/run-fail-twice.exp testcase:
>
> (gdb) run
> Starting program: .../gdb.base/run-fail-twice/run-fail-twice.nox
> Error creating process .../gdb.base/run-fail-twice/run-fail-twice.nox, (error 6: The handle is invalid.)
> (gdb) PASS: gdb.base/run-fail-twice.exp: test: bad run 1
> run
> Starting program: .../gdb.base/run-fail-twice/run-fail-twice.nox
> FAIL: gdb.base/run-fail-twice.exp: test: bad run 2 (timeout)
>
> The problem here is the same, except that this time it is
> windows_nat_target::create_inferior that returns the incorrect result.
>
> This commit fixes both the "attach" and "run" paths.  The tests
> mentioned above now pass on Cygwin.
>
> Change-Id: I15ec9fa279aff269d4982b00f4ea7c25ae917239
> ---
> gdb/windows-nat.c | 15 +++++++++------
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
> index b446afd72d8..5d2e23600e3 100644
> --- a/gdb/windows-nat.c
> +++ b/gdb/windows-nat.c
> @@ -2043,7 +2043,7 @@ windows_nat_target::attach (const char *args, int from_tty)
>       if (!ok)
>     err = (unsigned) GetLastError ();
>
> -      return true;
> +      return ok;
>     });
>
>   if (err.has_value ())
> @@ -2642,12 +2642,15 @@ windows_nat_target::create_inferior (const char *exec_file,
>   windows_init_thread_list ();
>   do_synchronously ([&] ()
>     {
> -      if (!create_process (nullptr, args, flags, w32_env,
> -              inferior_cwd != nullptr ? infcwd : nullptr,
> -              disable_randomization,
> -              &si, &pi))
> +      BOOL ok = create_process (nullptr, args, flags, w32_env,
> +                inferior_cwd != nullptr ? infcwd : nullptr,
> +                disable_randomization,
> +                &si, &pi);
> +
> +      if (!ok)
>     ret = (unsigned) GetLastError ();
> -      return true;
> +
> +      return ok;
>     });
>
>   if (w32_env)
>
> --
> 2.43.0

The same problem also exists in the !__CYGWIN__ branch, I ran into this
multiple times already.


Hannes