<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 16, 2017, at 5:58 AM, Howard Hellyer via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><font size="2" face="sans-serif" class="">Hi,</font>
<br class="">
<br class=""><font size="2" face="sans-serif" class="">I’ve been hitting issues connecting
to lldb-server. I’ve been trying from Mac to Linux running in a Virtual
Box VM on the same machine. Once I’ve created a target and issued the
“run” command lldb immediately disconnects with “error: connect remote
failed (failed to get reply to handshake packet)”. The full output from
a failed connection attempting to debug a simple "Hello World!"
program is:</font>
<br class="">
<br class=""><font size="2" face="sans-serif" class="">---</font>
<br class=""><font size="2" face="sans-serif" class="">(lldb) platform select remote-linux</font>
<br class=""><font size="2" face="sans-serif" class=""> Platform: remote-linux</font>
<br class=""><font size="2" face="sans-serif" class=""> Connected: no</font>
<br class=""><font size="2" face="sans-serif" class="">(lldb) platform connect <a href="connect://127.0.0.1:1234" class="">connect://127.0.0.1:1234</a></font>
<br class=""><font size="2" face="sans-serif" class=""> Platform: remote-linux</font>
<br class=""><font size="2" face="sans-serif" class=""> Triple: x86_64-pc-linux-gnu</font>
<br class=""><font size="2" face="sans-serif" class="">OS Version: 4.8.0 (4.8.0-22-generic)</font>
<br class=""><font size="2" face="sans-serif" class=""> Kernel: #24-Ubuntu SMP
Sat Oct 8 09:15:00 UTC 2016</font>
<br class=""><font size="2" face="sans-serif" class=""> Hostname: hhellyer-VirtualBox</font>
<br class=""><font size="2" face="sans-serif" class=""> Connected: yes</font>
<br class=""><font size="2" face="sans-serif" class="">WorkingDir: /home/hhellyer</font>
<br class=""><font size="2" face="sans-serif" class="">(lldb) target create hello.out</font>
<br class=""><font size="2" face="sans-serif" class="">Current executable set to 'hello.out'
(x86_64).</font>
<br class=""><font size="2" face="sans-serif" class="">(lldb) run</font>
<br class=""><font size="2" face="sans-serif" class="">error: connect remote failed (failed
to get reply to handshake packet)</font>
<br class=""><font size="2" face="sans-serif" class="">error: process launch failed: failed
to get reply to handshake packet</font>
<br class=""><font size="2" face="sans-serif" class="">--</font>
<br class="">
<br class=""><font size="2" face="sans-serif" class="">I’m running the server (on Linux) with:</font>
<br class=""><font size="2" face="sans-serif" class="">>lldb-server platform --listen *:1234
-P 2345</font>
<br class=""><font size="2" face="sans-serif" class="">(I need to specify the -P as only a
few ports are forwarded from the VirtualBox vm.)</font>
<br class="">
<br class=""><font size="2" face="sans-serif" class="">With logging enabled the logs showed
the failure happened when the lldb-server received </font><font size="2" face="Menlo-Regular" class="">the
"QStartNoAckMode" packet. </font></div></blockquote><div><br class=""></div><div>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 "<font face="Menlo-Regular" size="2" class="">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.</font></div><br class=""><blockquote type="cite" class=""><div class=""><font size="2" face="sans-serif" class="">I
initially thought this was a timing issue on the connection between the
client and the server. After doing some investigation I ended up adding
code to dump a backtrace when the connection was disconnected (in Communication::Disconnect)
and suddenly running the target started working. I replaced the backtrace
with a sleep(1) call and it continued working. After that I setup another
remote virtual linux box (actually some distance away on the network) and
found that lldb worked fine connecting to the remote lldb-server there,
presumably because the connection was much slower.</font>
<br class=""></div></blockquote><div><br class=""></div>We seem to have a race condition here. Any help figuring out what that might be would be great.<br class=""><blockquote type="cite" class=""><div class="">
<br class=""><font size="2" face="sans-serif" class="">At this point I was assuming it was
a timing issue however another configuration that worked was lldb-server
and lldb both running on the Linux VM inside Virtual Box which I would
have assumed would also be very quick. I’m also wondering if lldb does
anything special when the connection goes to 127.0.0.1 that using a local
VM might confuse.</font>
<br class=""></div></blockquote><div><br class=""></div><div><br class=""></div><div><div><div class="">So a little background on what happens:</div><div class="">- You launch lldb-server in platform mode on the remote host (VM in your case)</div><div class="">- We attach to it from LLDB on your host machine like you did above</div><div class="">- When we want to debug something on the other side ("run" command above), we send a packet to the lldb-server on the remote host and ask it to launch a GDB server for us. The lldb-server does launch one and sends back a hostname (<hostname>) and a port (<port>) in the response. The host side LLDB then tries to connect to this IP address and port using the equivalent of:</div><div class=""><br class=""></div><div class="">(lldb) process connect connect://<hostname>:<port></div><div class=""><br class=""></div><div class="">So the question is: does your VM have a unique IP address? if so, no port mapping will need to be done. If it responds with 127.0.0.1, then we have port collision issues and will probably need to use a port offsets. Typically with VMs there is some port remapping that has to happen. If you and your VM are both listening for a connection on port 1234, what happens if you would do:</div></div></div></div><div><br class=""></div><div>(lldb) platform connect <a href="connect://127.0.0.1:1234" class="">connect://127.0.0.1:1234</a> </div><div><br class=""></div><div>Would it connect to your host machine, or the VM? Typically there are some port remapping settings that you do. Like "add 10000" to any ports for the VM, so you would then just do:</div><div><br class=""></div><div>(lldb) platform connect <a href="connect://127.0.0.1:11234" class="">connect://127.0.0.1:11234</a> </div><div><br class=""></div><div>Notice the extra 10000 added to the original 1234. </div><div><br class=""></div><div>When starting the lldb-server in platform mode, you can ask it to use a min and max port range for connections so that you can edit your VM settings so that certain ports are available:</div><div><br class=""></div><div>% lldb-server platform --listen '*:1000' --min-gdbserver-port 1001 --max-gdbserver-port 1010 --port-offset=10000</div><div><br class=""></div><div>This would listen on port 1000, and reserver 1001 - 1010 for GDB remote connections when the server is asked to spawn a lldb-server in debug mode. Since you specified your port offset of 10000, when a packet is sent to your "lldb-server platform" that asks it to start a lldb-server for debugging it will use a port between 1001 and 1010 and when it sends the info back to the client it will add the port offset, so it will send back "11001" as the first port to connect to and the port remapping will know to talk to your VM.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><font size="2" face="sans-serif" class="">I was testing from Mac to Virtual Box
just because it was simpler than testing to a remote system, which was
actually the goal and seems to work, so this isn’t totally blocking me
but it does seem like a problem and I'm not sure if other users connecting
to remote linux machine will hit this problem. </font> <br class=""></div></blockquote><div><br class=""></div>Sounds like a race condition we need to solve.</div><div><br class=""><blockquote type="cite" class=""><div class=""><font size="2" face="sans-serif" class="">Are there any known issues around this
type of connection already? Or does anyone have any useful pointers? I
couldn’t see anything quite the same on </font><a href="http://bugs.llvm.org/" class=""><font size="2" color="blue" face="sans-serif" class="">http://bugs.llvm.org/</font></a><font size="2" face="sans-serif" class="">
so asking here seemed like a logical next step.</font>
<br class=""></div></blockquote><div><br class=""></div></div>This sounds like a very common VM issue. If you can elaborate on what happens with ports on your VM we might be able to deduce some of the problems. Filing a bug will be nice, but since you are running into this issue, seems like you will need to debug it and make it work. We are happy to assist.<div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Greg</div></body></html>