[lldb-dev] LLDB Process Attach Failed When Waiting

Mon Jun 4 17:17:55 PDT 2018

So I've found a capability on Linux to be notified about new processes.
I have an example of listening for these new processes running on my
machine now [1] and I can see when my desired user process spawns.
Though documentation on the API is scarce. It also requires that the
executable or user have the CAP_NET_ADMIN capability to run.
It's possible that the addition of this requirement is a non-starter.
Though I'm not 100% sure. Do you have any thoughts before I pursue
this further?
[1] http://bazaar.launchpad.net/~kees/+junk/cn_proc/files/3

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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180604/58e4e0c6/attachment.html>