<div dir="ltr">Greetings, I've been using liblldb to remotely debug to a linux server with port forwarding.  To do this, I start lldb-server to with --listen specifying a localhost port, as well as with ----min-gdbserver-port and --max-gdbserver-port to specify a specific port for use by 'gdb remote'.  Both ports are forwarded to the remote PC, where liblldb connects to localhost.<div><br>This generally works fine, but there is a race condition.  When the client tells lldb-server to start gdb-remote, the port is returned to the client which may try to connect before the gdb-remote process is actually listening.  Without port-forwarding, this is okay because the client has retry logic:</div><div><br></div><div>ProcessGDBRemote::ConnectToDebugserver<br></div><div>...</div><div><div>       retry_count++;</div><div>        if (retry_count >= max_retry_count)</div><div>          break;</div><div>        usleep(100000);</div></div><div><br></div><div>But with port-forwarding, the initial connection is always accepted by the port-forwarder, and only then does it try to establish a connection to the remote port.  It has no way to not accept the incoming local connection until it tries the remote end.</div><div><br></div><div>lldb has some logic to detect this further in the function, by using a handshake to ensure the connection is actually made:</div><div><br></div><div><div>  // We always seem to be able to open a connection to a local port</div><div>  // so we need to make sure we can then send data to it. If we can't</div><div>  // then we aren't actually connected to anything, so try and do the</div><div>  // handshake with the remote GDB server and make sure that goes</div><div>  // alright.</div><div>  if (!m_gdb_comm.HandshakeWithServer(&error)) {</div><div>    m_gdb_comm.Disconnect();</div><div>    if (error.Success())</div><div>      error.SetErrorString("not connected to remote gdb server");</div><div>    return error;</div><div>  }</div></div><div><br></div><div>But the problem here is that no retry is performed on failure.  The caller to the 'attach' API also can't retry because the gdb server is terminated on the error.</div><div><br></div><div>I would like to submit a patch, but first check to see if this solution would be acceptable:</div><div>- Include the handshake within the connection retry loop.</div><div>- This means fully disconnecting the re-establishing the connection in the loop if the handshake fails.</div><div>- Changing the timeout check to be based on a total absolute time instead of 50 iterations with a 100ms sleep.</div><div><br></div><div>Thoughts?</div><div><br></div><div>Alternatives could be:</div><div>- Have lldb-server delay responding to the 'start gdb server' request until it could tell (somehow) that the process is listening.</div><div>- A sleep of some kind on the client side after starting the server but before trying to connect.</div><div><br></div><div>Thanks,</div><div>Chris</div><div><br></div><div><br></div></div>