Re: [PATCH/RFC] gdbserver: Add command line option to not use SO_REUSEADDR

[Alan Hayward <Alan dot Hayward at arm dot com>]

> On 13 Feb 2019, at 21:05, Tom Tromey <tom@tromey.com> wrote:
> 
>>>>>> "Alan" == Alan Hayward <Alan.Hayward@arm.com> writes:
> 
> Alan> (Not sure if there is any additional documentation that will need
> Alan>  updating alongside this patch, or any other additions that need
> Alan>  to go alongside new command line flags).
> 
> There is some documentation on invoking gdbserver in the manual, so that
> should be updated.

Noted. I’ll put that into the next version, or raise an additional patch.

> 
> Alan> Forcing on gdb and gdbserver debug shows that for the failure cases
> Alan> gdbserver is launched, connects to gdb and sucessfully sends and
> Alan> receives packets.  Meanwhile on the gdb side, no packets are sent or
> Alan> received and the connection simply times out.  This indicates that
> Alan> the gdb from another running test has connected to this gdbserver.
> 
> Could you walk me through how this happens?  It seems strange to me that
> there could be any kind of race.  What I don't understand is that if two
> tests can run in parallel, both start gdbserver, and then one gdb can
> connect to the wrong server -- then it seems to me that the bug must be
> in the test suite itself?
> 

Sorry, totally missed replying to this part.  I’ll gather some more evidence
and get back to you next week.



> Alan> When running with -j55 on HEAD
> 
> Jealous.
> 
> Alan> 2019-02-12  Alan Hayward  <alan.hayward@arm.com>
> Alan> 	* remote-utils.c (remote_prepare): Check reuse flag.
> Alan> 	* server.c (gdbserver_usage): Add reuse help messages.
> Alan> 	(captured_main): Check for reuse flags
> Alan> 	* server.h (struct client_state): Add reuse flag.
> 
> FWIW the contents of the patch all seem fine to me.  But, I'd like to
> understand the problem better before approving it (and also there's the
> documentation).
> 
> thanks,
> Tom