This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[gdbserver/ob-ish] Fix mingw32 no-ack regression.
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Date: Tue, 31 Mar 2009 23:49:59 +0100
- Subject: [gdbserver/ob-ish] Fix mingw32 no-ack regression.
Just noticed this on mingw32 gdbserver:
$ ./gdb ./gdbserver/gdbserver.exe
:
(gdb) tar remote :9999
Remote debugging using :9999
Reading symbols from /cygdrive/c/WINDOWS/system32/ntdll.dll...done.
Loaded symbols for /cygdrive/c/WINDOWS/system32/ntdll.dll
:
0x7c911231 in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll
0x7c911231 <ntdll!DbgUiConnectToDbg+1>: ret
(gdb) c
Continuing.
Sending packet: $QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;4c;#8f...Packet received: OK
Sending packet: $vCont?#49...Packet received: vCont;c;C;s;S
Packet vCont (verbose-resume) is supported
Sending packet: $vCont;c#a8...Remote communication error: Connection reset by peer.
(gdb)
I was expecting a clean process exit, with exit code 1, that is: W01
While on the gdbserver side, one sees this:
$ ./gdbserver.exe --remote-debug :9999 ./gdbserver.exe
Process ./gdbserver.exe created; pid = 224
Listening on port 9999
:
getpkt ("vCont;c"); [no ack sent]
Usage: gdbserver [OPTIONS] COMM PROG [ARGS ...]
gdbserver [OPTIONS] --attach COMM PID
gdbserver [OPTIONS] --multi COMM
COMM may either be a tty device (for serial debugging), or
HOST:PORT to listen for a TCP connection.
Options:
--debug Enable general debugging output.
--remote-debug Enable remote protocol debugging output.
--version Display version information and exit.
--wrapper WRAPPER -- Run WRAPPER to start new programs.
putpkt ("$W01#b8"); [noack mode]
Child exited with status 1
GDBserver exiting
So, gdbserver did see the vCont;c, and thought it sent
the W01.
If I disable no-ack mode, with "set remote noack-packet off",
the problem goes away, which hints at some flushing problem.
Turns out that this particular "GDBserver exiting" path in gdbserver is
calling `exit(0)' without calling remote_close before. remote_close's job
is to explicitly close the socket. Both the detach and the
"monitor exit" paths call remote_close explicitly before
calling `exit'. I think this fact makes the patch below
obvious.
It appears that on WinSock, we need to call closesocket (or
alternativelly `shutdown', perhaps, I don't know), so data
is flushed, probably to the winsock layer. I didn't bother to
go investigate it.
Regression tested on x86_64-unknown-linux-gnu, as
paranoia measure, and checked in.
--
Pedro Alves
2009-03-31 Pedro Alves <pedro@codesourcery.com>
* server.c (main): After the inferior having exited, call
remote_close before exiting gdbserver.
---
gdb/gdbserver/server.c | 1 +
1 file changed, 1 insertion(+)
Index: src/gdb/gdbserver/server.c
===================================================================
--- src.orig/gdb/gdbserver/server.c 2009-03-31 22:10:31.000000000 +0100
+++ src/gdb/gdbserver/server.c 2009-03-31 22:31:46.858750000 +0100
@@ -1959,6 +1959,7 @@
else
{
fprintf (stderr, "GDBserver exiting\n");
+ remote_close ();
exit (0);
}
}