<tt><font size=2>Greg Clayton <gclayton@apple.com> wrote on 16/02/2017
17:17:41:<br>
<br>
<br>
> this is just the first packet we send after sending the "ack"
down <br>
> to the remote server. When we send the "ack", we don't need
a <br>
> response, then we send the "QStartNoAckMode" packet and
actually <br>
> wait for a response. If we don't get one, then we bail. So this is
<br>
> just the first packet that is sent that expects a response.</font></tt>
<br>
<br><tt><font size=2>I've been doing some more investigation and this seems
to be true but it looks like the actual "ack" might be part of
the problem.</font></tt>
<br>
<br><tt><font size=2>In GDBRemoteCommunicationClient::HandshakeWithServer
lldb sends an Ack() packet (a '+') then calls ReadPacket until it doesn't
succeed in reading any more packets to make sure everything outstanding
has been read.</font></tt>
<br><tt><font size=2>Then it does QueryNoAckModeSupported. What seems to
be happening in the passing case is that ReadPacket returns with a result
of ErrorReplyTimeout.</font></tt>
<br><tt><font size=2>In the failing case ReadPacket returns ErrorDisconnected.
This seems to be happening because in the failing case (without the delay)
the underlying "recv" call returns 0 indicating end-of-file and
then GDBRemoteCommunication::WaitForPacketNoLock calls Disconnect and returns
ErrorDisconnected to HandshakeWithServer.</font></tt>
<br><tt><font size=2>HandshakeWithServer seems to rely on ReadPacket failing
to read successfully but with a type of error that means the connection
is still valid. In the bad case it's failing with an error that means lldb
has disconnected.</font></tt>
<br>
<br><tt><font size=2>As yet I don't understand exactly why it reads an
empty response in the failing case. I'm not sure if there's something queued
or if it's managing to start talking to the remote process before it's
finished starting. Moving the sleep(1) just before GDBRemoteCommunicationClient::HandshakeWithServer
seems to work (with the sleep inside Disconnect() removed) so I think this
is on the right path.</font></tt>
<br>
<br><tt><font size=2>I'll continue investigating and see if I can determine
why. It might be the problem is on the server side and lldb-server is passing
back the connection details before the new process is ready for the client.<br>
</font></tt>
<br><tt><font size=2>Howard.</font></tt><font size=2 face="sans-serif"><br>
Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU<br>
</font>