[lldb-dev] Failure connecting to lldb-server running in local virtual machine.

[Howard Hellyer via lldb-dev]

Greg Clayton <gclayton at apple.com> wrote on 16/02/2017 17:17:41:


> this is just the first packet we send after sending the "ack" down 
> to the remote server. When we send the "ack", we don't need a 
> response, then we send the "QStartNoAckMode" packet and actually 
> wait for a response. If we don't get one, then we bail. So this is 
> just the first packet that is sent that expects a response.

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.

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.
Then it does QueryNoAckModeSupported. What seems to be happening in the 
passing case is that ReadPacket returns with a result of 
ErrorReplyTimeout.
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.
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.

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.

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.

Howard.
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170220/4f8acd94/attachment.html>