This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[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);
 		}
 	    }


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]