<tt><font size=2>Greg Clayton <gclayton@apple.com> wrote on 16/02/2017
17:17:41:</font></tt>
<br>
<br><tt><font size=2>> We seem to have a race condition here. Any help
figuring out what <br>
> that might be would be great.</font></tt>
<br>
<br><tt><font size=2>I think I've now identified the problem.</font></tt>
<br>
<br><tt><font size=2>Normally in lldb-server when the child lldb-server
process is launched inside GDBRemoteCommunication::StartDebugserverProcess
the parent lldb-server waits for it to start up and write back the port
is has selected to listen on a pipe.</font></tt>
<br><tt><font size=2>When lldb-server specifies a port for the child to
listen on (when we start lldb-server with -P <port> or -m <minport>
and -M <maxport>) then it doesn't bother setting up that pipe as
it knows what the port will be. However not listening means the parent
can reply to the lldb client with the port number before the debugserver
process is actually up and and listening on that port.</font></tt>
<br>
<br><tt><font size=2>Simply making sure the pipe is always setup and used
to read the port number from (even when lldb-server knows what it will
be) ensures the child process is ready and allows me to connect reliably
with an unmodified client lldb.</font></tt>
<br>
<br><tt><font size=2>The one second delay in the client was fixing things
as inside PlatformRemoteGDBServer::DebugProcess there is a retry to ConnectRemote
and the delay gave time for the child process to begin before the retry.
This also explains why more people weren't seeing this problem as it only
applies if you use the -P or -m/-M options. I think I only found those
by searching the code, they don't appear in the help for lldb-server when
you run it and I didn't manage to find any docs.</font></tt>
<br>
<br><tt><font size=2>Unless anyone points out a major flaw in the logic
above I'll tidy up my fix and put a patch up on </font></tt><a href=https://reviews.llvm.org/><tt><font size=2 color=blue>https://reviews.llvm.org/</font></tt></a><tt><font size=2>
in the next few days. The code for listening on a pipe from the child process
is slightly different when __APPLE__ is defined so I need to verify the
change on Mac and Linux. I'll probably just always read back the port and
if it comes back as an unexpected value that may need to be a new error
case.</font></tt>
<br>
<br><tt><font size=2>Would you mind if I also raised a patch to update
the documentation to include the -P and -m/-M options? (Both in the help
when you run lldb-server and on www/remote.html.) I originally came to
this problem because another team couldn't connect to a remote system with
only certain ports open and found them the options they needed by reading
the source and I think doing things like connecting to processes in a VM
or docker container where these options are needed are becoming more common.</font></tt>
<br><tt><font size=2>Thanks,</font></tt>
<br>
<br><tt><font size=2>Howard.</font></tt>
<br><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>