| Summary: | gdbserver --once --multi mishandles run & attach failures | ||
|---|---|---|---|
| Product: | gdb | Reporter: | Pedro Alves <pedro> |
| Component: | server | Assignee: | Pedro Alves <pedro> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | unknown | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
Got patch for "run", and noticed "attach" also has the same problem while writing an unrelated testcase... The master branch has been updated by Pedro Alves <palves@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ec48903170926f3827144525b50ddd3c6ae3fbf0 commit ec48903170926f3827144525b50ddd3c6ae3fbf0 Author: Pedro Alves <pedro@palves.net> Date: Mon Mar 25 15:17:02 2024 +0000 New testcase gdb.threads/leader-exit-attach.exp (PR threads/8153) Add a new testcase for exercising attaching to a process after its main thread has exited. This is not possible on Linux, the kernel does not allow attaching to a zombie task, so the test is kfailed there. It is possible however on Windows at least, and was the scenario addressed by the Windows backend fix in https://sourceware.org/legacy-ml/gdb-patches/2003-12/msg00479.html, nowadays PR threads/8153, back in 2003. Passes cleanly on Cygwin. KFAILed on GNU/Linux native and gdbserver. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=8153 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31554 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31555 Change-Id: Ib554f92f68c965bb4603cdf2aadb55ca45ded53b The master branch has been updated by Pedro Alves <palves@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f1fc8dc2dccb4a224cdd1c3973c7a09a752aa95b commit f1fc8dc2dccb4a224cdd1c3973c7a09a752aa95b Author: Pedro Alves <pedro@palves.net> Date: Wed Apr 17 19:26:32 2024 +0100 Fix "attach" failure handling with GDBserver This fixes the same issue as the previous patch, but for "attach" instead of "run". If attaching to a process with "attach" (vAttach packet) fails, GDBserver throws an error that escapes all the way to the top level. When an error escapes all the way like that, GDBserver interprets it as a disconnection, and either goes back to waiting for a new GDB connection, or exits, if --once was specified. Here's an example: On the GDB side: ... (gdb) tar extended-remote :9999 ... Remote debugging using :9999 (gdb) attach 1 Attaching to process 1 Attaching to process 1 failed (gdb) On the GDBserver side: $ gdbserver --once --multi :9999 Listening on port 9999 Remote debugging from host 127.0.0.1, port 37464 gdbserver: Cannot attach to process 1: Operation not permitted (1) $ # gdbserver exited This is wrong, as we've connected with extended-remote/--multi. GDBserver should just report an error to vAttach, and continue connected to GDB, waiting for other commands. This commit fixes GDBserver by catching the error locally in handle_v_attach. Note we now let pid == 0 pass down to attach_inferior. That is so we get a useful textual error message to report to GDB. This fixes a couple KFAILs in gdb.base/attach.exp. Still, I thought it would be useful to add a new testcase specifically for this scenario, in case gdb.base/attach.exp is ever split and stops trying to attach again after a failed attach, with the same GDB session. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19558 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31554 Change-Id: I25314c7e5f1435eff69cb84d57ecac13d8de3393 Approved-By: Tom Tromey <tom@tromey.com> All fixed. |
"gdbserver --once --multi" mishandles run or attach failures. GDBserver exits/disconnects on run/attach failure, but it should not. From --help: --multi Start server without a specific program, and only quit when explicitly commanded. --once Exit after the first connection has closed. E.g., for "run": On GDB side: ... (gdb) tar extended-remote :9999 ... Remote debugging using :9999 (gdb) r Starting program: Running ".../gdb.base/run-fail-twice/run-fail-twice.nox" on the remote target failed (gdb) On GDBserver side: $ gdbserver --once --multi :9999 Remote debugging from host 127.0.0.1, port 34344 bash: line 1: .../gdb.base/run-fail-twice/run-fail-twice.nox: Permission denied bash: line 1: exec: .../gdb.base/run-fail-twice/run-fail-twice.nox: cannot execute: Permission denied gdbserver: During startup program exited with code 126. $ # gdbserver exited This gdbserver exit is wrong, as we've connected with extended-remote/--multi. Here's an example for "attach": On GDB side: ... (gdb) tar extended-remote :9999 ... Remote debugging using :19999 (gdb) attach 1 Attaching to process 1 Attaching to process 1 failed (gdb) On GDBserver side: $ gdbserver --once --multi :9999 Listening on port 9999 Remote debugging from host 127.0.0.1, port 37464 gdbserver: Cannot attach to process 1: Operation not permitted (1) $ # gdbserver exited This gdbserver exit is also wrong, as we've connected with extended-remote/--multi.