On 04/06/2013 08:26 PM, Jan Kratochvil wrote:
> On Fri, 22 Mar 2013 20:18:41 +0100, Jan Kratochvil wrote:
>> +set server_pid [exp_pid -i [board_info target fileid]]
>> +remote_exec target "kill -9 $server_pid"
>> +
>> +gdb_test "step" "Remote connection closed"
> 
> Getting occasionally randomly:
> 	Remote communication error.  Target disconnected.: Connection reset by peer.
> 	(gdb) FAIL: gdb.server/server-kill.exp: tstatus
> 
> (it was FAILing on "step" before, "tstatus" vs. "step" does not matter)
> 
> I even Googled one may get ECONNRESET by writing into a closed TCP socket:
> 	http://stackoverflow.com/questions/2974021/what-does-econnreset-mean-in-the-context-of-an-af-local-socket
>
> But I was unable to reproduce it myself (kernel-3.8.4-202.fc18.x86_64) with
> the attached testcase:
> 	sleeping ... done
> 	write ok
> 	ssize=0
> 	read ok
> 	send: send.c:53: main: Unexpected error: Broken pipe.
> 	Aborted
> by:
>  * nc -l 5000
>  * ./send (starts sleeping)
>  * kill -9 `pidof ncat` (Fedora nc is ncat)
>  * # send resumes sleeping
> 
> I get at most EPIPE but never ECONNRESET.  send vs. write and recv vs. read
> also make no difference there.

From that url:

"Triggered when there's outstanding outgoing data that has not yet been written to the other side."

ncat is recv'ing the data you send it, so the window that
could trigger is quite small.

I've attached a standalone (no ncat) reproducer that triggers it all
the time for me.

$ ./send
sleeping ... closing ... done
send: send.c:72: main: Unexpected error: Connection reset by peer.
Aborted

> With no answer I will check in this patch as this issue seems unrelated to the
> problem, GDB still works properly even with ECONNRESET.  I was just curious.

Looks fine to me.

-- 
Pedro Alves