[lldb-dev] LLDB Process Attach Failed When Waiting

Wed Jun 6 04:50:21 PDT 2018

Thank you. That get me moving again. I will also see if there is anything I could contribute to lldb-gdb-remote.txt regarding the format of this packet.

On Wed, Jun 6, 2018, at 3:59 AM, Pavel Labath wrote:
> There is some documentation on the packets in docs/lldb-gdb-remote.txt
> in the lldb repo, though for this particular packet it does not say
> much about the encoding (patches welcome).
> 
> That said, it looks like the format is just that we send the process
> name hex-encoded. For that you can simply use
> StringExtractor.GetHexBytes. There should be plenty of examples doing
> hex {en|de}coding around the codebase.
> On Wed, 6 Jun 2018 at 03:51, Ryan Lovelett via lldb-dev
> <lldb-dev at lists.llvm.org> wrote:
> >
> > Thank you that was a huge help.  I'm making some progress now.
> >
> > Though I wonder, is there any documentation of the GDB packet format? The reason I ask is that I'm trying to figure out to get the process name from vAttach.
> >
> > I've looked at how debugserver does it, namely the method GetProcessNameFrom_vAttach [1], and I cannot seem to find the equivalent method in StringExtractorGDBRemote or StringExtractor (though I'll admit that it might be obvious and I'm just missing it). If that's the case I imagine I'll have to implement it and I would like to at least understand the packet format to do that.
> >
> > [1] https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/tools/debugserver/source/RNBRemote.cpp#L3585
> >
> > On Tue, Jun 5, 2018, at 9:03 PM, Jim Ingham wrote:
> > > Except for Windows and FreeBSD, lldb uses a server program to do the
> > > actual debugging - either debugserver on Darwin or lldb-server
> > > elsewhere.  The interface to these servers (and to the in-process
> > > debugging in Windows & FreeBSD) is abstracted being Process Plugins,
> > > which the generic code uses.  Target::Attach is in generic code, it
> > > won't know anything about the actual method used to attach, wait for
> > > attach, whatever.  That will be dispatched to the currently active
> > > ProcessPlugin.
> > >
> > > ProcessGDBRemote is the plugin that is used on Linux & Darwin.  It is
> > > the code that actually talks to debugserver or lldb-rpc-server from
> > > within lldb.  And that's the code in lldb that sends the vAttachWait
> > > gdb-remote protocol packet to instruct the above-mentioned servers to
> > > implement attach-wait.  That request works on Darwin because debugserver
> > > handles the vAttachWait packet, but doesn't work on Linux because lldb-
> > > rpc-server doesn't know currently respond to the vAttachWait packet.  So
> > > all you should need to do is teach lldb-server to handle the vAttachWait
> > > packet.
> > >
> > > Jim
> > >
> > >
> > > > On Jun 5, 2018, at 5:44 PM, Ryan Lovelett via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> > > >
> > > > I think I might be a little lost. I built a lldb in debug mode and I am running lldb in an lldb debugger (very meta).
> > > >
> > > > Earlier in the thread you said "we need a better error message when vAttachWait returns unsupported" I have found where the error message, e.g., "error: attach failed: lost connection" is constructed. The "attach failed: " comes from here [1] and the "lost connection" comes from here [2].
> > > >
> > > > What do you mean by "vAttachWait"? Am I missing something obvious?
> > > >
> > > > It seems like you are expecting lldb-server to be the place where the fix will be implemented. Though in the debugger I'm seeing the method Target::Attach() [3] as the place where the connection attempt is made and fails.
> > > >
> > > > [1] https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Commands/CommandObjectProcess.cpp#L518
> > > > [2] https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Target/Target.cpp#L3444-L3445
> > > > [3] https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Target/Target.cpp#L3374
> > > >
> > > > On Mon, Jun 4, 2018, at 7:04 PM, Greg Clayton wrote:
> > > >> I will be too busy this week to get to this, so please do have a stab at it.
> > > >>
> > > >> Basically the flow that debug server does is:
> > > >> 1 - get a list of all processes whose basename matches and remember those pids so we don't try to attach to them since we are waiting for a new process to show up
> > > >> 2 - poll the OS for the process list and wait for a new pid to show up with the basename and attach to the first one that matches whose pid isn't i the list from step #1
> > > >>
> > > >> On MacOSX we don't have a way to be notified of new processes are spawned, not sure on other unix variants. If it is possible, we would want change to:
> > > >> 1 - sign up to be notified about new processes
> > > >> 2 - as each process gets launched, check for a match and attach as quickly as possible
> > > >>
> > > >> Hope this helps and I look forward to seeing your patch!
> > > >>
> > > >> Greg
> > > >>
> > > >>> On Jun 4, 2018, at 5:56 AM, Ryan Lovelett <ryan at lovelett.me> wrote:
> > > >>>
> > > >>> Greg,
> > > >>>
> > > >>> Is there anything I can do to help you implement or test this feature? Obviously I'm willing to roll-up my sleeves and work on this myself too if you've become more busy than you expected. That happens to us all and I completely understand.
> > > >>>
> > > >>> Not being able to debug in this manner is blocking me from adding Linux support to a Swift program. As you might imagine, I'm a little antsy to get past this so I can start writing some code.
> > > >>>
> > > >>> On Thu, May 31, 2018, at 5:08 PM, Greg Clayton wrote:
> > > >>>>
> > > >>>>
> > > >>>>> On May 31, 2018, at 12:40 PM, Ryan Lovelett <ryan at lovelett.me> wrote:
> > > >>>>>
> > > >>>>> Well at least there is a little good news. I understood way more of those logs than I thought I did.
> > > >>>>>
> > > >>>>>> So two issues here:
> > > >>>>>> 1 - we need a better error message when vAttachWait returns unsupported
> > > >>>>>> 2 - fix lldb-server to support vAttachWait
> > > >>>>>
> > > >>>>> A few questions.
> > > >>>>>
> > > >>>>> What is the protocol here? Can/should I report the issues at https://bugs.llvm.org/ ? Or is that something that a project member needs to do? Assuming that I can, would this be two seperate issues or one "large" issue?
> > > >>>>>
> > > >>>>> Barring that this is not something someone else might implement better/faster than me. Considering I have zero LLDB development experience is this something that I could tackle?
> > > >>>>
> > > >>>> I didn't realize this functionality was missing in lldb-server. I can take a stab at implementing it and see what I can do. Stay tuned.
> > > >>>>
> > > >>>>>
> > > >>>>> On Thu, May 31, 2018, at 3:02 PM, Greg Clayton wrote:
> > > >>>>>> lldb-server claims it doesn't support it:
> > > >>>>>>
> > > >>>>>> lldb             <  48> send packet: $vAttachWait;6c616e677365727665722d7377696674#d6
> > > >>>>>> lldb             <   4> read packet: $#00
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> Returning the empty packet ("$#00") means it is not supported, but we really should give a better error message than this.
> > > >>>>>>
> > > >>>>>> It isn't that hard to implement. It would be easy to copy the code that is in debugserver in DNB.cpp in the DNBProcessAttachWait function. Most of it is probably posix style stuff.
> > > >>>>>>
> > > >>>>>> So two issues here:
> > > >>>>>> 1 - we need a better error message when vAttachWait returns unsupported
> > > >>>>>> 2 - fix lldb-server to support vAttachWait
> > > >>>>>>
> > > >>>>>> Greg
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>> On May 31, 2018, at 11:04 AM, Ryan Lovelett <ryan at lovelett.me> wrote:
> > > >>>>>>>
> > > >>>>>>>> It might be a lldb-server issue?
> > > >>>>>>>
> > > >>>>>>> How would one go about determining this?
> > > >>>>>>>
> > > >>>>>>> (lldb) log enable -f /tmp/packates.txt gdb-remote packets
> > > >>>>>>> (lldb) process attach --name "<name>" --waitfor
> > > >>>>>>> error: attach failed: lost connection
> > > >>>>>>>
> > > >>>>>>> Attached the log output. Maybe it'll make more sense to you than me.
> > > >>>>>>>
> > > >>>>>>> That escalated quickly. So I've read through that log. I found something that says $qVAttachOrWaitSupported#38 with the following response being $#00. Perhaps I'm reading too much but is it that it's reporting that it is not supported?
> > > >>>>>>>
> > > >>>>>>> Does lldb-server need to be compiled in a certain way to add support for attach wait?
> > > >>>>>>>
> > > >>>>>>> On Thu, May 31, 2018, at 1:49 PM, Greg Clayton wrote:
> > > >>>>>>>> Try enabling logging with:
> > > >>>>>>>>
> > > >>>>>>>> (lldb) log enable -f /tmp/packets.txt gdb-remote packets
> > > >>>>>>>>
> > > >>>>>>>> And the try the attach. It might be a lldb-server issue?
> > > >>>>>>>>
> > > >>>>>>>>> On May 31, 2018, at 9:02 AM, Ryan Lovelett via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>> I am attempting to use: process attach --name "<name>" --waitfor
> > > >>>>>>>>>
> > > >>>>>>>>> The problem is that it immediately returns error: attach failed: lost connection.
> > > >>>>>>>>>
> > > >>>>>>>>> Is this something I can troubleshoot further? Or is this not supported on Linux?
> > > >>>>>>>>>
> > > >>>>>>>>> --
> > > >>>>>>>>> Ryan Lovelett
> > > >>>>>>>>> _______________________________________________
> > > >>>>>>>>> lldb-dev mailing list
> > > >>>>>>>>> lldb-dev at lists.llvm.org
> > > >>>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> > > >>>>>>> <packates.txt>
> > > >
> > > > _______________________________________________
> > > > lldb-dev mailing list
> > > > lldb-dev at lists.llvm.org
> > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> > >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev