[lldb-dev] Get source-map from python API?

[Jeffrey Tan via lldb-dev]

Hi,

We are building an IDE debugger on top of lldb python API. In order to get
the source remapping work(the source path embedded in the symbol may be
different from the real source path), user needs to use "settings set
target.source-map" command to remap the source.

I would like users to do similar thing from our IDE debugger. However, I
could not find a python API to specify the source remapping, and more
important a way to access the remapping functionality. The SBSourceManager
class only exposes a single DisplaySourceLinesWithLineNumbers() method
which displays the source in console output. Ideally it should expose an
API in SBSourceManager for us to provide the old FileSpec and get back a
new remapped FileSpec.

Is this not exposed in Python API? Do I need to re-do the remapping logic
in our IDE UI code? How is other IDE handling the source remapping?

Thanks
Jeffrey
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Bad state of release 3.7.1?

[Jeffrey Tan via lldb-dev]

Hi,

My colleague downloaded and built 3.7.1 version of lldb on Linux. When we
used it to attach to a normal process(like sleep), it just hangs forever:

bin/lldb -n sleep
(lldb) process attach --name "sleep"

And my private built 3.8.0 version works fine.

Just to confirm, is 3.7.1 a bad version? Is there any known issue about it?

Thanks
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Bad state of release 3.7.1?

[Jeffrey Tan via lldb-dev]

Btw: here is the source that we built lldb from:

http://llvm.org/releases/download.html#3.7.1

direct link http://llvm.org/releases/3.7.1/lldb-3.7.1.src.tar.xz

On Mon, Jan 25, 2016 at 2:37 PM, Jeffrey Tan 
wrote:

> Hi,
>
> My colleague downloaded and built 3.7.1 version of lldb on Linux. When we
> used it to attach to a normal process(like sleep), it just hangs forever:
>
> bin/lldb -n sleep
> (lldb) process attach --name "sleep"
>
> And my private built 3.8.0 version works fine.
>
> Just to confirm, is 3.7.1 a bad version? Is there any known issue about it?
>
> Thanks
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Bad state of release 3.7.1?

[Jeffrey Tan via lldb-dev]

Thanks David.
I am new to lldb group but it's kind of surprise to me that the lldb on the
official release page(http://llvm.org/releases/download.html#3.7.1) can
have such big problems(can't attach/launch). Don't we fully test lldb
before we post on the official website?



On Mon, Jan 25, 2016 at 4:12 PM, David Jones  wrote:

> This is a known problem with 3.7.1.
>
> It should be fixed for 3.8. You should be able to try out 3.8rc1 right now.
>
>
>
> On Mon, Jan 25, 2016 at 5:37 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hi,
>>
>> My colleague downloaded and built 3.7.1 version of lldb on Linux. When we
>> used it to attach to a normal process(like sleep), it just hangs forever:
>>
>> bin/lldb -n sleep
>> (lldb) process attach --name "sleep"
>>
>> And my private built 3.8.0 version works fine.
>>
>> Just to confirm, is 3.7.1 a bad version? Is there any known issue about
>> it?
>>
>> Thanks
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Bad state of release 3.7.1?

[Jeffrey Tan via lldb-dev]

Btw: is there a fix that we can cherry pick? Or is it safe for us to build
lldb 3.8rc1 with llvm3.7.1?

On Mon, Jan 25, 2016 at 4:34 PM, Jeffrey Tan 
wrote:

> Thanks David.
> I am new to lldb group but it's kind of surprise to me that the lldb on
> the official release page(http://llvm.org/releases/download.html#3.7.1)
> can have such big problems(can't attach/launch). Don't we fully test lldb
> before we post on the official website?
>
>
>
> On Mon, Jan 25, 2016 at 4:12 PM, David Jones 
> wrote:
>
>> This is a known problem with 3.7.1.
>>
>> It should be fixed for 3.8. You should be able to try out 3.8rc1 right
>> now.
>>
>>
>>
>> On Mon, Jan 25, 2016 at 5:37 PM, Jeffrey Tan via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> Hi,
>>>
>>> My colleague downloaded and built 3.7.1 version of lldb on Linux. When
>>> we used it to attach to a normal process(like sleep), it just hangs forever:
>>>
>>> bin/lldb -n sleep
>>> (lldb) process attach --name "sleep"
>>>
>>> And my private built 3.8.0 version works fine.
>>>
>>> Just to confirm, is 3.7.1 a bad version? Is there any known issue about
>>> it?
>>>
>>> Thanks
>>>
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>>
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Understanding debugger launch events sequence

[Jeffrey Tan via lldb-dev]

Hi,

On mac OS, I am having difficulty understanding the launch debugger events
sequence of lldb. I used the following code to play around LLDB. I found,
for some binaries, debugger will enter stopped/paused mode, waiting for my
further input, print stack shows:
dbg> bt
* thread #1: tid = 0x15153e, 0x7fff5fc0d2af
dyld`gdb_image_notifier(dyld_image_mode, unsigned int, dyld_image_info
const*) + 1
  * frame #0: 0x7fff5fc0d2af dyld`gdb_image_notifier(dyld_image_mode,
unsigned int, dyld_image_info const*) + 1
frame #1: 0x401d

But some other binaries, it just print "Process event: stopped, reason: 1"
and inferior just exits immediately without waiting for debugger's further
input.

Questions:
1. When I launch a binary, is there supposed to be a loader breakpoint
waiting for debugger continue? Any other debug events do I expect to get
and continue?
2. What about attach?
3. What is the dyld`gdb_image_notifier() debugger break above? Why does it
happen for some binary but not others?

Thanks for any information!

# Should be first for LLDB package to be added to search path.
from find_lldb import lldb
from lldb import eStateStepping, eStateRunning, eStateExited, SBBreakpoint,
SBEvent, SBListener, SBProcess, SBTarget
import sys
import os
import subprocess
from sys import stdin, stdout
from threading import Thread

class LLDBListenerThread(Thread):
should_quit = False

def __init__(self, process):
  Thread.__init__(self)
  self.listener = SBListener('Chrome Dev Tools Listener')
  self._add_listener_to_process(process)
  self._broadcast_process_state(process)
  self._add_listener_to_target(process.target)

def _add_listener_to_target(self, target):
# Listen for breakpoint/watchpoint events
(Added/Removed/Disabled/etc).
broadcaster = target.GetBroadcaster()
mask = SBTarget.eBroadcastBitBreakpointChanged |
SBTarget.eBroadcastBitWatchpointChanged |
SBTarget.eBroadcastBitModulesLoaded
broadcaster.AddListener(self.listener, mask)

def _add_listener_to_process(self, process):
# Listen for process events (Start/Stop/Interrupt/etc).
broadcaster = process.GetBroadcaster()
mask = SBProcess.eBroadcastBitStateChanged
broadcaster.AddListener(self.listener, mask)

def _broadcast_process_state(self, process):
state = 'stopped'
if process.state == eStateStepping or process.state ==
eStateRunning:
state = 'running'
elif process.state == eStateExited:
state = 'exited'
self.should_quit = True
thread = process.selected_thread
print 'Process event: %s, reason: %d' % (state,
thread.GetStopReason())

def _breakpoint_event(self, event):
breakpoint = SBBreakpoint.GetBreakpointFromEvent(event)
print 'Breakpoint event: %s' % str(breakpoint)

def run(self):
while not self.should_quit:
event = SBEvent()
if self.listener.WaitForEvent(1, event):
if event.GetType() == SBTarget.eBroadcastBitModulesLoaded:
print 'Module load: %s' % str(event)
elif SBProcess.EventIsProcessEvent(event):

self._broadcast_process_state(SBProcess.GetProcessFromEvent(event))
elif SBBreakpoint.EventIsBreakpointEvent(event):
self._breakpoint_event(event)

def _interctive_loop(debugger):
process = debugger.GetSelectedTarget().process
event_thread = LLDBListenerThread(process)
event_thread.start()

while (True):
stdout.write('dbg> ')
command = stdin.readline().rstrip()
if len(command) == 0:
continue
debugger.HandleCommand(command)


def main():
debugger = lldb.SBDebugger.Create()

print('Working Directory: %s' % os.getcwd())
debugger.HandleCommand('target create /usr/bin/find')
debugger.HandleCommand('run .')
_interctive_loop(debugger)

if __name__ == '__main__':
main()
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Understanding debugger launch events sequence

[Jeffrey Tan via lldb-dev]

Thanks Jim. Is this true for other platforms? Our IDE is going to support
Mac and Linux and may extend to Windows some time later.
Just curious, why does Xcode create multiple SBDebuggers assuming it is
debugging a single process? Are you talking about multiple-processes
scenario(One SBDebugger for one process)?


On Fri, Jan 29, 2016 at 9:21 AM, Jim Ingham  wrote:

> There is no requirement that the lldb API’s be called on a particular
> thread on OS X.  LLDB tries to be robust against being called from multiple
> threads simultaneously for the same debugger, but you can still make it
> fall over if you try hard, particularly if you allow multiple threads to
> restart the process you are debugging.  Running multiple SBDebuggers on
> separate threads works fine, that’s the mode Xcode uses, and we haven’t had
> problems with this in quite a while.
>
> Jim
>
> > On Jan 29, 2016, at 8:54 AM, Jeffrey.fudan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Great, this is very helpful, will give a try.
> > Btw: is there any threading requirement of lldb API? For example, are
> all the Apis must be called on the event thread or they are free to be
> called on any thread? I know windows debug API has some limitation on this.
> >
> > Sent from my iPad
> >
> >> On Jan 29, 2016, at 2:59 AM, Pavel Labath  wrote:
> >>
> >> Hi Jeffrey,
> >>
> >> I see a couple of problems with the way you are using the lldb's API.
> >> The main problem is you are launching the target via the command-line
> >> API, which does not allow you to specify the listener upon creation.
> >> When you start it this way all events go to the default debugger
> >> listener (debugger.GetListener()), and by the time you connect your
> >> own listener, some of these events have already been broadcast, and
> >> that is why you get nondeterministic behavior. You should use the
> >> SBTarget.Launch function to specify the listener from the start.
> >>
> >> The second problem is the handling of the Stopped events. Sometimes
> >> LLDB needs to stop the inferior do to some internal work, but this the
> >> program is immediately resumed. This event is broadcast as a "stopped"
> >> event with a special "restarted" bit set (see
> >> SBProcess.GetRestartedFromEvent, and
> >> <http://lists.llvm.org/pipermail/lldb-dev/2016-January/009291.html>)
> >>
> >> hope that helps,
> >> pl
> >>
> >>
> >>
> >> On 29 January 2016 at 03:53, Jeffrey Tan via lldb-dev
> >>  wrote:
> >>> Hi,
> >>>
> >>> On mac OS, I am having difficulty understanding the launch debugger
> events
> >>> sequence of lldb. I used the following code to play around LLDB. I
> found,
> >>> for some binaries, debugger will enter stopped/paused mode, waiting
> for my
> >>> further input, print stack shows:
> >>> dbg> bt
> >>> * thread #1: tid = 0x15153e, 0x7fff5fc0d2af
> >>> dyld`gdb_image_notifier(dyld_image_mode, unsigned int, dyld_image_info
> >>> const*) + 1
> >>> * frame #0: 0x7fff5fc0d2af dyld`gdb_image_notifier(dyld_image_mode,
> >>> unsigned int, dyld_image_info const*) + 1
> >>>   frame #1: 0x401d
> >>>
> >>> But some other binaries, it just print "Process event: stopped,
> reason: 1"
> >>> and inferior just exits immediately without waiting for debugger's
> further
> >>> input.
> >>>
> >>> Questions:
> >>> 1. When I launch a binary, is there supposed to be a loader breakpoint
> >>> waiting for debugger continue? Any other debug events do I expect to
> get and
> >>> continue?
> >>> 2. What about attach?
> >>> 3. What is the dyld`gdb_image_notifier() debugger break above? Why
> does it
> >>> happen for some binary but not others?
> >>>
> >>> Thanks for any information!
> >>>
> >>> # Should be first for LLDB package to be added to search path.
> >>> from find_lldb import lldb
> >>> from lldb import eStateStepping, eStateRunning, eStateExited,
> SBBreakpoint,
> >>> SBEvent, SBListener, SBProcess, SBTarget
> >>> import sys
> >>> import os
> >>> import subprocess
> >>> from sys import stdin, stdout
> >>> from threading import Thread
> >>>
> >>> class LLDBListenerThread(Thread):
> >>>   should_quit

Re: [lldb-dev] Understanding debugger launch events sequence

[Jeffrey Tan via lldb-dev]

Jim/Pavel, my toy code works reliably after using SBListener with
SBTarget.Launch/Attach.
One thing I noticed is:
If I set "stop_at_entry=True" for SBTarget.Launch(), I will get a stop
event of eStopReasonSignal at loader breakpoint. However
SBTarget.AttachXXX() will pause the target process without a stop event. Is
this expected? This may cause a bit state issue in our IDE since we rely on
the stop event from debugger to update UI in IDE. Is there any way to tell
lldb to emit a stop event during attach?


On Fri, Jan 29, 2016 at 11:22 AM, Jim Ingham  wrote:

> I can’t comment on Windows, I don’t know what requirements the Windows
> API’s place on the debugger.
>
> Its been a while since I’ve worked on Linux, but I don’t remember anything
> that would privilege one thread over another.
>
> lldb supports running multiple targets and processes in one debugger, and
> also supports multiple debuggers running each one target or any
> combination.  Since each Debugger gets a separate script interpreter (and
> all its state) by running multiple processes in one SBDebugger you could
> offer users the possibility of having scripted commands to control a set of
> processes (e.g. hitting a breakpoint in one process could trigger actions
> in the other.)  It might be possible to do some interesting things that
> way.
>
> OTOH, keeping to one process per debugger is a much simpler programming
> model.  So if you were planning to have YOUR code that runs the debugger
> handle the possible interactions among processes, then it is probably going
> to be easier to manage doing it that way.
>
> Jim
>
>
>
> On Jan 29, 2016, at 10:43 AM, Jeffrey Tan  wrote:
>
> Thanks Jim. Is this true for other platforms? Our IDE is going to support
> Mac and Linux and may extend to Windows some time later.
> Just curious, why does Xcode create multiple SBDebuggers assuming it is
> debugging a single process? Are you talking about multiple-processes
> scenario(One SBDebugger for one process)?
>
>
> On Fri, Jan 29, 2016 at 9:21 AM, Jim Ingham  wrote:
>
>> There is no requirement that the lldb API’s be called on a particular
>> thread on OS X.  LLDB tries to be robust against being called from multiple
>> threads simultaneously for the same debugger, but you can still make it
>> fall over if you try hard, particularly if you allow multiple threads to
>> restart the process you are debugging.  Running multiple SBDebuggers on
>> separate threads works fine, that’s the mode Xcode uses, and we haven’t had
>> problems with this in quite a while.
>>
>> Jim
>>
>> > On Jan 29, 2016, at 8:54 AM, Jeffrey.fudan via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>> >
>> > Great, this is very helpful, will give a try.
>> > Btw: is there any threading requirement of lldb API? For example, are
>> all the Apis must be called on the event thread or they are free to be
>> called on any thread? I know windows debug API has some limitation on this.
>> >
>> > Sent from my iPad
>> >
>> >> On Jan 29, 2016, at 2:59 AM, Pavel Labath  wrote:
>> >>
>> >> Hi Jeffrey,
>> >>
>> >> I see a couple of problems with the way you are using the lldb's API.
>> >> The main problem is you are launching the target via the command-line
>> >> API, which does not allow you to specify the listener upon creation.
>> >> When you start it this way all events go to the default debugger
>> >> listener (debugger.GetListener()), and by the time you connect your
>> >> own listener, some of these events have already been broadcast, and
>> >> that is why you get nondeterministic behavior. You should use the
>> >> SBTarget.Launch function to specify the listener from the start.
>> >>
>> >> The second problem is the handling of the Stopped events. Sometimes
>> >> LLDB needs to stop the inferior do to some internal work, but this the
>> >> program is immediately resumed. This event is broadcast as a "stopped"
>> >> event with a special "restarted" bit set (see
>> >> SBProcess.GetRestartedFromEvent, and
>> >> <http://lists.llvm.org/pipermail/lldb-dev/2016-January/009291.html>)
>> >>
>> >> hope that helps,
>> >> pl
>> >>
>> >>
>> >>
>> >> On 29 January 2016 at 03:53, Jeffrey Tan via lldb-dev
>> >>  wrote:
>> >>> Hi,
>> >>>
>> >>> On mac OS, I am having difficulty understanding the launch debugger
>> events
>> >>> sequence o

Re: [lldb-dev] Understanding debugger launch events sequence

[Jeffrey Tan via lldb-dev]

Thanks. That's fine, just want to confirm the behavior and my
understanding. I can definitely deal with the difference between
attach/launch myself.

On Fri, Jan 29, 2016 at 1:41 PM, Jim Ingham  wrote:

> I don’t think we can change this behavior, since other clients are relying
> on the way it is now.
>
> In any case, attach won't return till it is successful, and presumably you
> know you are attaching, so I don’t think there’s any ambiguity about what
> is going on, even if you don’t get a stop event.
>
> Jim
>
> On Jan 29, 2016, at 11:50 AM, Jeffrey Tan  wrote:
>
> Jim/Pavel, my toy code works reliably after using SBListener with
> SBTarget.Launch/Attach.
> One thing I noticed is:
> If I set "stop_at_entry=True" for SBTarget.Launch(), I will get a stop
> event of eStopReasonSignal at loader breakpoint. However
> SBTarget.AttachXXX() will pause the target process without a stop event. Is
> this expected? This may cause a bit state issue in our IDE since we rely on
> the stop event from debugger to update UI in IDE. Is there any way to tell
> lldb to emit a stop event during attach?
>
>
> On Fri, Jan 29, 2016 at 11:22 AM, Jim Ingham  wrote:
>
>> I can’t comment on Windows, I don’t know what requirements the Windows
>> API’s place on the debugger.
>>
>> Its been a while since I’ve worked on Linux, but I don’t remember
>> anything that would privilege one thread over another.
>>
>> lldb supports running multiple targets and processes in one debugger, and
>> also supports multiple debuggers running each one target or any
>> combination.  Since each Debugger gets a separate script interpreter (and
>> all its state) by running multiple processes in one SBDebugger you could
>> offer users the possibility of having scripted commands to control a set of
>> processes (e.g. hitting a breakpoint in one process could trigger actions
>> in the other.)  It might be possible to do some interesting things that
>> way.
>>
>> OTOH, keeping to one process per debugger is a much simpler programming
>> model.  So if you were planning to have YOUR code that runs the debugger
>> handle the possible interactions among processes, then it is probably going
>> to be easier to manage doing it that way.
>>
>> Jim
>>
>>
>>
>> On Jan 29, 2016, at 10:43 AM, Jeffrey Tan 
>> wrote:
>>
>> Thanks Jim. Is this true for other platforms? Our IDE is going to support
>> Mac and Linux and may extend to Windows some time later.
>> Just curious, why does Xcode create multiple SBDebuggers assuming it is
>> debugging a single process? Are you talking about multiple-processes
>> scenario(One SBDebugger for one process)?
>>
>>
>> On Fri, Jan 29, 2016 at 9:21 AM, Jim Ingham  wrote:
>>
>>> There is no requirement that the lldb API’s be called on a particular
>>> thread on OS X.  LLDB tries to be robust against being called from multiple
>>> threads simultaneously for the same debugger, but you can still make it
>>> fall over if you try hard, particularly if you allow multiple threads to
>>> restart the process you are debugging.  Running multiple SBDebuggers on
>>> separate threads works fine, that’s the mode Xcode uses, and we haven’t had
>>> problems with this in quite a while.
>>>
>>> Jim
>>>
>>> > On Jan 29, 2016, at 8:54 AM, Jeffrey.fudan via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>> >
>>> > Great, this is very helpful, will give a try.
>>> > Btw: is there any threading requirement of lldb API? For example, are
>>> all the Apis must be called on the event thread or they are free to be
>>> called on any thread? I know windows debug API has some limitation on this.
>>> >
>>> > Sent from my iPad
>>> >
>>> >> On Jan 29, 2016, at 2:59 AM, Pavel Labath  wrote:
>>> >>
>>> >> Hi Jeffrey,
>>> >>
>>> >> I see a couple of problems with the way you are using the lldb's API.
>>> >> The main problem is you are launching the target via the command-line
>>> >> API, which does not allow you to specify the listener upon creation.
>>> >> When you start it this way all events go to the default debugger
>>> >> listener (debugger.GetListener()), and by the time you connect your
>>> >> own listener, some of these events have already been broadcast, and
>>> >> that is why you get nondeterministic behavior. You should use the
>>> >> SBTarget.Launch function to specify the 

[lldb-dev] How to get SBTarget before AttachToProcessWithID?

[Jeffrey Tan via lldb-dev]

Hi,

Normally if you want to attach to a process you only have the pid/name of
the process. How do you get SBTarget? Am I supposed to call
SBDebugger.CreateTargetWithFileAndArch() against a dummy executable? Why do
we require a dummy SBTarget before attaching? This seems to be a wrong
design to me... Thanks.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Listening for thread events

[Jeffrey Tan via lldb-dev]

What event_mask should be used for the thread event class? I did not find
any. (Sorry for hijacking the thread)

On Fri, Jan 29, 2016 at 4:02 PM, Jim Ingham via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> It’s unclear to me why it would be a problem to listen to every thread
> object?  They aren’t terribly chatty or anything, and you can listen to all
> of them with one listener.
>
> Note, you don’t have to sign up individually for every thread object’s
> broadcaster.  That would be really annoying.  In lldb, you can listen to
> individual broadcasters or “broadcaster event classes”.  You want to do the
> latter.
>
> You get the event class name with the GetBroadcasterClassName method on
> the class you are interested in (SBThread in this case) and then on your
> listener call
>
> SBListener::StartListeningForEventClass
>
> If you do that, the debugger will sign your listener up for the objects of
> that broadcaster class as they come and go.  That makes listening to events
> on all the threads in your process quite straightforward.
>
> Hope this helps.
>
> Jim
>
>
> On Jan 29, 2016, at 2:32 PM, John Lindal via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> I'm building an X11 UI on top of LLDB, and I'm stuck trying to listen for
> thread events.
>
> lldb_private::Thread is a Broadcaster, but lldb::SBThread doesn't expose a
> GetBroadcaster() event the way SBProcess does.
>
> I wouldn't really want to have to listen to every SBThread object, but
> when the program stops, I could listen to the selected thread.  (Getting
> the events from SBProcess would also work, if Process relayed them.)
>
> Is this a feature that has not yet been implemented?  I couldn't find any
> related tickets in Bugzilla.
>
> Thanks,
> John Lindal
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Listening for thread events

[Jeffrey Tan via lldb-dev]

Never mind, found the thread event_mask in threads.h. They are just not in
the python API reference page.

On Sat, Jan 30, 2016 at 10:28 PM, Jeffrey Tan 
wrote:

> What event_mask should be used for the thread event class? I did not find
> any. (Sorry for hijacking the thread)
>
> On Fri, Jan 29, 2016 at 4:02 PM, Jim Ingham via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> It’s unclear to me why it would be a problem to listen to every thread
>> object?  They aren’t terribly chatty or anything, and you can listen to all
>> of them with one listener.
>>
>> Note, you don’t have to sign up individually for every thread object’s
>> broadcaster.  That would be really annoying.  In lldb, you can listen to
>> individual broadcasters or “broadcaster event classes”.  You want to do the
>> latter.
>>
>> You get the event class name with the GetBroadcasterClassName method on
>> the class you are interested in (SBThread in this case) and then on your
>> listener call
>>
>> SBListener::StartListeningForEventClass
>>
>> If you do that, the debugger will sign your listener up for the objects
>> of that broadcaster class as they come and go.  That makes listening to
>> events on all the threads in your process quite straightforward.
>>
>> Hope this helps.
>>
>> Jim
>>
>>
>> On Jan 29, 2016, at 2:32 PM, John Lindal via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> I'm building an X11 UI on top of LLDB, and I'm stuck trying to listen for
>> thread events.
>>
>> lldb_private::Thread is a Broadcaster, but lldb::SBThread doesn't expose
>> a GetBroadcaster() event the way SBProcess does.
>>
>> I wouldn't really want to have to listen to every SBThread object, but
>> when the program stops, I could listen to the selected thread.  (Getting
>> the events from SBProcess would also work, if Process relayed them.)
>>
>> Is this a feature that has not yet been implemented?  I couldn't find any
>> related tickets in Bugzilla.
>>
>> Thanks,
>> John Lindal
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] How to get SBTarget before AttachToProcessWithID?

[Jeffrey Tan via lldb-dev]

Thanks guys, will give empty target a try.

On Mon, Feb 1, 2016 at 12:10 PM, Jim Ingham  wrote:

> Often when attaching, you know the executable you are planning to attach
> to.  So the "normal" workflow is to create a target, then attach to the
> process with that target's executable.  This is particularly useful for
> remote debugging, since having a local copy of the binary will mean less
> data lldb has to ship over the remote connection.  It also means you can
> prep the target with breakpoints & settings prior to attach.
>
> The case where you don't know the binary before you attach is a degenerate
> case of this, and so the sensible thing is to create an empty target, and
> use that to attach.  Then attaching will fill in this empty target.
>
> That makes more sense to me than having the debugger - which is the only
> thing above the target - support "Attach to anonymous app" but the target
> do "attach to known app".
>
> BTW, the most straightforward way to create an empty target is to call
> SBDebugger.CreateTarget("").  I added a note to this effect in the
> SBDebugger help preamble.
>
> Jim
>
> > On Feb 1, 2016, at 2:02 AM, Pavel Labath via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hi,
> >
> > it's a bit un-intuitive, but you should be able to create a target
> > with a null pointer for the executable, and use that to attach (see
> > CommandObjectProcessAttach::DoExecute).
> >
> > BTW, if you find the existing API documentation too vague, we'd be
> > happy to accept any improvements.
> >
> > cheers,
> > pl
> >
> >
> > On 30 January 2016 at 05:42, Jeffrey Tan via lldb-dev
> >  wrote:
> >> Hi,
> >>
> >> Normally if you want to attach to a process you only have the pid/name
> of
> >> the process. How do you get SBTarget? Am I supposed to call
> >> SBDebugger.CreateTargetWithFileAndArch() against a dummy executable?
> Why do
> >> we require a dummy SBTarget before attaching? This seems to be a wrong
> >> design to me... Thanks.
> >>
> >>
> >>
> >> ___
> >> lldb-dev mailing list
> >> lldb-dev@lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >>
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Debug events in synchronous mode?

[Jeffrey Tan via lldb-dev]

Hi,

I found that if I am using synchronous mode, some times there are no debug
events generated during launch. For example, for the code
below, LLDBListenerThread will receive no debug events.

Is this expected? What is the rule of debug events in synchronous mode?

def main():
debugger = lldb.SBDebugger.Create()
debugger.SetAsync(False)
target = debugger.CreateTargetWithFileAndArch(executable_path,
lldb.LLDB_ARCH_DEFAULT)
target.BreakpointCreateByName('main')

listener = lldb.SBListener('Event Listener')
error = lldb.SBError()
process = target.Launch (listener,
 None,  # argv
 None,  # envp
 None,  # stdin_path
 None,  # stdout_path
 None,  # stderr_path
 None,  # working directory
 0, # launch flags
 False, # Stop at entry
 error) # error
print 'Launch result: %s' % str(error)
event_thread = LLDBListenerThread(debugger)
event_thread.start()
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Debug events in synchronous mode?

[Jeffrey Tan via lldb-dev]

Jim, thanks for the confirmation. It seems to me that there are many
quirks of LLDB API that you have to be aware of before you can
automate it correctly. Are these quirks documented somewhere that I
missed? I have looked at examples/tests folders of LLDB and python API
pages, both do not have enough depths as the discussions here.


> On Feb 4, 2016, at 11:23 AM, Jim Ingham  wrote:
>
> In synchronous mode, you should never see events.  The part of lldb that is 
> making the command synchronous is using those events to make the command wait 
> till the action it initiated completes before it returns.  If it is letting 
> process control events leak out, then that is a bug.
>
> If you are running in async mode (and haven't set stop-at-entry in the launch 
> options), then you won't see an event till the process stops for some other 
> reason (e.g. hitting a breakpoint.)  If launch returns with no error, then 
> your process got launched, and you should just wait for it to stop.
>
> Jim
>
>> On Feb 4, 2016, at 1:21 AM, Pavel Labath via lldb-dev 
>>  wrote:
>>
>> Hi,
>>
>> I am not sure what are the "official" rules, but the general idea is
>> that you need not concern yourself too much with events when you are
>> in synchronous mode. In synchronous mode, you can be sure that by the
>> time target.Launch() returns, the process will be stopped (or dead, or
>> something else, you can check process.GetState() to find that out). No
>> need to play around with listeners...
>>
>> cheers,
>> pl
>>
>> On 4 February 2016 at 06:41, Jeffrey Tan via lldb-dev
>>  wrote:
>>> Hi,
>>>
>>> I found that if I am using synchronous mode, some times there are no debug
>>> events generated during launch. For example, for the code below,
>>> LLDBListenerThread will receive no debug events.
>>>
>>> Is this expected? What is the rule of debug events in synchronous mode?
>>>
>>> def main():
>>>   debugger = lldb.SBDebugger.Create()
>>>   debugger.SetAsync(False)
>>>   target = debugger.CreateTargetWithFileAndArch(executable_path,
>>> lldb.LLDB_ARCH_DEFAULT)
>>>   target.BreakpointCreateByName('main')
>>>
>>>   listener = lldb.SBListener('Event Listener')
>>>   error = lldb.SBError()
>>>   process = target.Launch (listener,
>>>None,  # argv
>>>None,  # envp
>>>None,  # stdin_path
>>>None,  # stdout_path
>>>None,  # stderr_path
>>>None,  # working directory
>>>0, # launch flags
>>>False, # Stop at entry
>>>error) # error
>>>   print 'Launch result: %s' % str(error)
>>>   event_thread = LLDBListenerThread(debugger)
>>>   event_thread.start()
>>>
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Race condition crashes during launching LLDB

[Jeffrey Tan via lldb-dev]

Hi,

I am revising our lldb automation tests into async mode. However, I found
it randomly crashes depends on timing. And the crash happens mostly while
launching lldb twice in a row. I have narrowed down the code into a simple
repro below. Any assumption I made wrong with the LLDB API here?

The crash stack seems to be not consistently. In the small repro below, the
crash stack is:
Crashed Thread:0  Dispatch queue: com.apple.main-thread

Exception Type:EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:   EXC_I386_GPFLT

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   _lldb.so   0x0001088c7179
EventMatcher::operator()(std::__1::shared_ptr const&)
const + 21
1   _lldb.so   0x0001088c65d2
lldb_private::Listener::FindNextEventInternal(lldb_private::Broadcaster*,
lldb_private::ConstString const*, unsigned int, unsigned int,
std::__1::shared_ptr&, bool) + 176
2   _lldb.so   0x0001088c6952
lldb_private::Listener::WaitForEventsInternal(lldb_private::TimeValue
const*, lldb_private::Broadcaster*, lldb_private::ConstString const*,
unsigned int, unsigned int, std::__1::shared_ptr&) +
134
3   _lldb.so   0x0001088c6ae9
lldb_private::Listener::WaitForEventForBroadcasterWithType(lldb_private::TimeValue
const*, lldb_private::Broadcaster*, unsigned int,
std::__1::shared_ptr&) + 27
4   _lldb.so   0x000108abce6c
lldb_private::Process::WaitForStateChangedEvents(lldb_private::TimeValue
const*, std::__1::shared_ptr&,
lldb_private::Listener*) + 112
5   _lldb.so   0x000108abcc95
lldb_private::Process::WaitForProcessToStop(lldb_private::TimeValue const*,
std::__1::shared_ptr*, bool, lldb_private::Listener*,
lldb_private::Stream*) + 377
6   _lldb.so   0x000108ac516a
lldb_private::Process::HaltForDestroyOrDetach(std::__1::shared_ptr&)
+ 216
7   _lldb.so   0x000108abc8b0
lldb_private::Process::Destroy(bool) + 146
8   _lldb.so   0x000108abc56d
lldb_private::Process::Finalize() + 91
9   _lldb.so   0x0001088b63c4
lldb_private::Debugger::Clear() + 148
10  _lldb.so   0x0001088b61fd
lldb_private::Debugger::Destroy(std::__1::shared_ptr&)
+ 37
11  _lldb.so   0x000106bdb144
lldb::SBDebugger::Destroy(lldb::SBDebugger&) + 116
12  _lldb.so   0x000106c23daf
_wrap_SBDebugger_Destroy(_object*, _object*) + 120
13  org.python.python 0x0001058dd75f PyEval_EvalFrameEx +
12761

while in the real unit test it is crashing at:
Thread 12 Crashed:
0   libsystem_kernel.dylib 0x7fff8635a286 __pthread_kill + 10
1   libsystem_c.dylib 0x7fff919409b3 abort + 129
2   libc++abi.dylib   0x7fff8a94ea21 abort_message + 257
3   libc++abi.dylib   0x7fff8a9769d1
default_terminate_handler() + 267
4   libobjc.A.dylib   0x7fff935e77eb _objc_terminate() + 124
5   libc++abi.dylib   0x7fff8a9740a1 std::__terminate(void
(*)()) + 8
6   libc++abi.dylib   0x7fff8a973b30 __cxa_throw + 121
7   com.apple.LLDB.framework   0x00010b994c6b
std::__1::shared_ptr::shared_ptr(std::__1::weak_ptr
const&, std::__1::enable_if::value,
std::__1::shared_ptr::__nat>::type) + 99
8   com.apple.LLDB.framework   0x00010b8ac762
lldb_private::Process::AppendSTDOUT(char const*, unsigned long) + 86
9   com.apple.LLDB.framework   0x00010b6951d7
lldb_private::Communication::ReadThread(void*) + 287
10  libsystem_pthread.dylib   0x7fff8d92c05a _pthread_body + 131
11  libsystem_pthread.dylib   0x7fff8d92bfd7 _pthread_start + 176


Repro Code

def wait_for_process_stop(process):
while not process.is_stopped:
time.sleep(0.1)

def launch_debugging(debugger, stop_at_entry):
error = lldb.SBError()
listener = lldb.SBListener('Chrome Dev Tools Listener')
target = debugger.GetSelectedTarget()
process = target.Launch (listener,
None,  # argv
None,  # envp
None,  # stdin_path
None,  # stdout_path
None,  # stderr_path
None,  # working directory
0, # launch flags
stop_at_entry,  # Stop at entry
error) # error
print 'Launch result: %s' % str(error)
event_thread = LLDBListenerThread(debugger)
event_thread.start()
return process

def do_test():
debugger = lldb.SBDebugger.Create()
debugger.SetAsync(True)
target = debugger.CreateTargetWithFileAndArch(executable_path,
lldb.LLDB_ARCH_DEFAULT)

process = launch_debugging(debugger, stop_at_entry=True)

wait_for_process_stop(process) # wait for entry breakpoint.
target.Breakpo

Re: [lldb-dev] Race condition crashes during launching LLDB

[Jeffrey Tan via lldb-dev]

elif lldb.SBThread.EventIsThreadEvent(event):
> self._handle_thread_event(event)
> else:
> self._handle_unknown_event(event)
>
> _hand_XXX_event() methods just dump some logging information of the debug
> events.
>
>
> Crashed Thread:0  Dispatch queue: com.apple.main-thread
>
> Exception Type:EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes:   EXC_I386_GPFLT
>
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0   _lldb.so   0x000111528179
> EventMatcher::operator()(std::__1::shared_ptr const&)
> const + 21
> 1   _lldb.so   0x0001115275d2
> lldb_private::Listener::FindNextEventInternal(lldb_private::Broadcaster*,
> lldb_private::ConstString const*, unsigned int, unsigned int,
> std::__1::shared_ptr&, bool) + 176
> 2   _lldb.so   0x000111527952
> lldb_private::Listener::WaitForEventsInternal(lldb_private::TimeValue
> const*, lldb_private::Broadcaster*, lldb_private::ConstString const*,
> unsigned int, unsigned int, std::__1::shared_ptr&) +
> 134
> 3   _lldb.so   0x000111527ae9
> lldb_private::Listener::WaitForEventForBroadcasterWithType(lldb_private::TimeValue
> const*, lldb_private::Broadcaster*, unsigned int,
> std::__1::shared_ptr&) + 27
> 4   _lldb.so   0x00011171de6c
> lldb_private::Process::WaitForStateChangedEvents(lldb_private::TimeValue
> const*, std::__1::shared_ptr&,
> lldb_private::Listener*) + 112
> 5   _lldb.so   0x00011171dc95
> lldb_private::Process::WaitForProcessToStop(lldb_private::TimeValue const*,
> std::__1::shared_ptr*, bool, lldb_private::Listener*,
> lldb_private::Stream*) + 377
> 6   _lldb.so   0x00011172616a
> lldb_private::Process::HaltForDestroyOrDetach(std::__1::shared_ptr&)
> + 216
> 7   _lldb.so   0x00011171d8b0
> lldb_private::Process::Destroy(bool) + 146
> 8   _lldb.so   0x00011171d56d
> lldb_private::Process::Finalize() + 91
> 9   _lldb.so   0x0001115173c4
> lldb_private::Debugger::Clear() + 148
> 10  _lldb.so   0x0001115171fd
> lldb_private::Debugger::Destroy(std::__1::shared_ptr&)
> + 37
> 11  _lldb.so   0x00010f83c144
> lldb::SBDebugger::Destroy(lldb::SBDebugger&) + 116
> 12  _lldb.so   0x00010f884daf
> _wrap_SBDebugger_Destroy(_object*, _object*) + 120
> 13  org.python.python 0x00010e53e75f PyEval_EvalFrameEx +
> 12761
>
>
> On Thu, Feb 4, 2016 at 5:37 PM, Jim Ingham  wrote:
>
>> I don't know what:
>>
>> event_thread = LLDBListenerThread(debugger)
>>
>> does, but from your little sketch it looks like you are starting up a
>> thread listening on this debugger, and so far as I can see you destroy the
>> debugger out from under it without ever closing down that thread.  That
>> doesn't seem like a good idea.
>>
>> Jim
>>
>>
>>
>>
>> > On Feb 4, 2016, at 5:27 PM, Jeffrey Tan via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>> >
>> > Hi,
>> >
>> > I am revising our lldb automation tests into async mode. However, I
>> found it randomly crashes depends on timing. And the crash happens mostly
>> while launching lldb twice in a row. I have narrowed down the code into a
>> simple repro below. Any assumption I made wrong with the LLDB API here?
>> >
>> > The crash stack seems to be not consistently. In the small repro below,
>> the crash stack is:
>> > Crashed Thread:0  Dispatch queue: com.apple.main-thread
>> >
>> > Exception Type:EXC_BAD_ACCESS (SIGSEGV)
>> > Exception Codes:   EXC_I386_GPFLT
>> >
>> > Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
>> > 0   _lldb.so  0x0001088c7179
>> EventMatcher::operator()(std::__1::shared_ptr const&)
>> const + 21
>> > 1   _lldb.so  0x0001088c65d2
>> lldb_private::Listener::FindNextEventInternal(lldb_private::Broadcaster*,
>> lldb_private::ConstString const*, unsigned int, unsigned int,
>> std::__1::shared_ptr&, bool) + 176
>> > 2   _lldb.so  0x0001088c6952
>> lldb_private::Listener::WaitForEventsInternal(lldb_private::TimeValue
>> const*, lldb_private::Broadcaster*, lldb_private::ConstString const*,
>> unsigned int, unsigned int, std::__1::shared_ptr&) +
>> 134
>> > 3  

Re: [lldb-dev] Race condition crashes during launching LLDB

[Jeffrey Tan via lldb-dev]

Thanks Pavel, yeah, that's what I figured out yesterday.
In "So now Destroy starts destroying the process while it is just being
*started up* and things go south", for "started up", I assume you mean
inferior is not *continued/resumed* from first entry point breakpoint,
right? The inferior is definitely started and hitting the first entry point
breakpoint because of the first "wait_for_process_stop()" call. Just want
to confirm we are on the same page.

I have revised my sample code to use two thread.Event to synchronize
running/stopping between main thread and listener thread, the race
condition seems to go away after running it 10 times in a loop. I will
integrate this logic into our unit test to see if it fixed the race crash.


On Fri, Feb 5, 2016 at 1:42 AM, Pavel Labath  wrote:

> On 5 February 2016 at 05:09, Jeffrey Tan via lldb-dev
>  wrote:
> > After adding some logging I figured out that the race condition is
> caused by
> > process.Continue() did not guarantee process has been really resumed yet
> in
> > async mode, so the second wait_for_process_stop() is skipped immediately
> to
> > kill listener thread and destroying debugger. I know I have a race
> condition
> > bug here because of polling for process state, but why is lldb crashing
> when
> > listener thread has exited and SBDebugger.Destroy() is called? What is
> the
> > situation that SBDebugger.Destroy() can be called safely?
>
> My guess on the sequence of events here is this:
> - call process.Continue(), which returns immediately
> - you check process.is_stopped, which is still true
> - set self.should_quit = true
> - listener thread exits and you join in
> - you call SBDebugger.Destroy()
>
> all of this happens _before_ the process has had a chance to really
> start. So now Destroy starts destroying the process while it is just
> being started up and things go south. It could be argued that this is
> a bug in LLDB (this is the reason our TestEvents is disabled). I've
> been investigating this a bit, but it did not look easy.
>
> In any case, what you can do now is to make sure you wait for the
> eStateRunning event before you try to do anything to the process
> (including killing it). These paths are more tested and they I believe
> they should be stable.
>
> pl
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Why is storing SBTarget in a private field causing random crash?

[Jeffrey Tan via lldb-dev]

Hi,

I have been spending long time troubleshooting a race condition in our lldb
python test. I finally narrowed down to one code change that caused the
race: basically, whenever I store SBTarget in DebuggerTestCase's
self.target field lldb will randomly crash during destruction(see below).

In the code, if I modify the two "self.target" to local variable "target"
the random crash will disappear.

I am not a python expert. Why is holding SBTarget will cause the test to
random crash? Do I have to set every SBXXX fields to None before
calling SBDebugger.Destroy()?


==Crash Stack==
Crashed Thread:0  Dispatch queue: com.apple.main-thread

Exception Type:EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:   KERN_INVALID_ADDRESS at 0x0010

VM Regions Near 0x10:
-->
__TEXT 00010d145000-00010d146000 [4K]
r-x/rwx SM=COW
 
/System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.apple.LLDB.framework   0x0001101c037d
lldb_private::Listener::BroadcasterWillDestruct(lldb_private::Broadcaster*)
+ 95
1   com.apple.LLDB.framework   0x0001101a0da2
lldb_private::Broadcaster::Clear() + 50
2   com.apple.LLDB.framework   0x0001101a0ced
lldb_private::Broadcaster::~Broadcaster() + 75
3   com.apple.LLDB.framework   0x0001103d6879
lldb_private::Target::~Target() + 741
4   com.apple.LLDB.framework   0x0001103d6c20
lldb_private::Target::~Target() + 14
5   libc++.1.dylib 0x7fff896448a6
std::__1::__shared_weak_count::__release_shared() + 44
6   com.apple.LLDB.framework   0x00010e560664
_wrap_delete_SBTarget(_object*, _object*) + 123
7   org.python.python 0x00010d15a50a PyObject_Call + 99


==Code==
from find_lldb import lldb
from simplest_event_thread import LLDBListenerThread
import unittest
import threading

running_signal = threading.Event()
stopped_signal = threading.Event()

def launch_debugging(debugger, stop_at_entry):
error = lldb.SBError()
listener = lldb.SBListener('Chrome Dev Tools Listener')
target = debugger.GetSelectedTarget()
process = target.Launch (listener,
None,  # argv
None,  # envp
None,  # stdin_path
None,  # stdout_path
None,  # stderr_path
None,  # working directory
0, # launch flags
stop_at_entry,  # Stop at entry
error) # error
print 'Launch result: %s' % str(error)

event_thread = LLDBListenerThread(debugger, running_signal,
stopped_signal)
event_thread.start()

running_signal.set()
return event_thread

class DebuggerTestCase:

def wait_for_process_stop(self):
running_signal.wait()
running_signal.clear()
stopped_signal.wait()
stopped_signal.clear()

def test_breakpoint_at_line(self):
debugger = lldb.SBDebugger.Create()
debugger.SetAsync(True)
executable_path =
'~/Personal/compiler/CompilerConstruction/code/compiler'
*self.target* =
debugger.CreateTargetWithFileAndArch(executable_path,
lldb.LLDB_ARCH_DEFAULT)

event_thread = launch_debugging(debugger, stop_at_entry=True)

process = debugger.GetSelectedTarget().process
self.wait_for_process_stop() # wait for entry breakpoint.
*self.target*.BreakpointCreateByName('main')
process.Continue()
self.wait_for_process_stop() # wait for main breakpoint.

event_thread.should_quit = True
event_thread.join()
lldb.SBDebugger.Destroy(debugger)

if __name__ == '__main__':
test = DebuggerTestCase()
for i in range(20):
test.test_breakpoint_at_line()
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] No stopping event during launch(stop_at_entry=True) on Linux?

[Jeffrey Tan via lldb-dev]

Hi,

I have got lldb launch working fine on my macbook for sometime. But when I
try the same code on Linux, it failed to emit any stopping events during
initial launch.

When I run the reproduce code(listed at the end), I got the following
different results:

The key difference is that Macbook will emit a stopped event which caused
our IDE UI to enter break mode, while Linux violates this assumption. Is
this a bug?

==Mac==
lldb_pythonpath:
/Applications/Xcode.app/Contents/Developer/../SharedFrameworks/LLDB.framework/Resources/Python
Launch result: success
 Listening Thread ID: 4610625536
dbg> *Target event: ModulesLoaded*
*Process event: StateChanged, Stopped*
*Stop reason: 5*
dbg> bt
* thread #1: tid = 0x101f01d, 0x7fff6401a000 dyld`_dyld_start, stop
reason = signal SIGSTOP
  * frame #0: 0x7fff6401a000 dyld`_dyld_start
==Mac==

==Linux==
python linux_launch.py
find_lldb: 
Launch result: success
 Listening Thread ID: 140316621375232
dbg> bt
* thread #1: tid = 2794520, 0x7f6165b7bb00, name = 'foo', stop reason =
signal SIGSTOP
  * frame #0: 0x7f6165b7bb00
==Linux==

Repro main.py
# Should be first for LLDB package to be added to search path.
from find_lldb import lldb
import sys
import os
import time
from sys import stdin, stdout
from event_thread import LLDBListenerThread
import threading


def interctive_loop(debugger):
while (True):
stdout.write('dbg> ')
command = stdin.readline().rstrip()
if len(command) == 0:
continue
if command == 'q':
return
debugger.HandleCommand(command)

def do_test():
debugger = lldb.SBDebugger.Create()
debugger.SetAsync(True)
executable_path =
'~/Personal/compiler/CompilerConstruction/code/compiler'
target = debugger.CreateTargetWithFileAndArch(executable_path,
lldb.LLDB_ARCH_DEFAULT)

listener = lldb.SBListener('Event Listener')
error = lldb.SBError()
process = target.Launch (listener,
 None,  # argv
 None,  # envp
 None,  # stdin_path
 None,  # stdout_path
 None,  # stderr_path
 None,  # working directory
 0, # launch flags
 True, # Stop at entry
 error) # error
print 'Launch result: %s' % str(error)

running_signal = threading.Event()
stopped_signal = threading.Event()
event_thread = LLDBListenerThread(debugger, running_signal,
stopped_signal)
event_thread.start()

interctive_loop(debugger)

event_thread.should_quit = True
event_thread.join()

lldb.SBDebugger.Destroy(debugger)
return debugger

def main():
debugger = do_test()

if __name__ == '__main__':
main()

Event_thread
class LLDBListenerThread(Thread):
should_quit = False

def __init__(self, debugger, running_signal=None, stopped_sigal=None):
  Thread.__init__(self)
  self._running_signal = running_signal
  self._stopped_sigal = stopped_sigal
  process = debugger.GetSelectedTarget().process
  self.listener = debugger.GetListener()
  self._add_listener_to_process(process)
  self._add_listener_to_target(process.target)


def _add_listener_to_target(self, target):
# Listen for breakpoint/watchpoint events
(Added/Removed/Disabled/etc).
broadcaster = target.GetBroadcaster()
mask = lldb.SBTarget.eBroadcastBitBreakpointChanged |
lldb.SBTarget.eBroadcastBitWatchpointChanged |
lldb.SBTarget.eBroadcastBitModulesLoaded
broadcaster.AddListener(self.listener, mask)

def _add_listener_to_process(self, process):
# Listen for process events (Start/Stop/Interrupt/etc).
broadcaster = process.GetBroadcaster()
mask = lldb.SBProcess.eBroadcastBitStateChanged |
lldb.SBProcess.eBroadcastBitSTDOUT | lldb.SBProcess.eBroadcastBitSTDERR |
lldb.SBProcess.eBroadcastBitInterrupt
broadcaster.AddListener(self.listener, mask)

def run(self):
print ' Listening Thread ID: %d' % thread.get_ident()
while not self.should_quit:
event = lldb.SBEvent()
if self.listener.WaitForEvent(1, event):
if lldb.SBTarget.EventIsTargetEvent(event):
self._handle_target_event(event)
elif lldb.SBProcess.EventIsProcessEvent(event):
self._handle_process_event(event)
elif lldb.SBBreakpoint.EventIsBreakpointEvent(event):
self._handle_breakpoint_event(event)
elif lldb.SBThread.EventIsThreadEvent(even

Re: [lldb-dev] No stopping event during launch(stop_at_entry=True) on Linux?

[Jeffrey Tan via lldb-dev]

I am not sure. From the output, it seems lldb does stop at the entry
point(because you can issue "bt" command to dump the stack) in both
platforms; the problem seems to be that it did not emit the stopped event
for its stop on linux.

On Tue, Feb 23, 2016 at 2:03 PM, Jim Ingham  wrote:

> If the linux side is not obeying "stop_at_entry" then that is a bug.
>
> Jim
>
>
> > On Feb 23, 2016, at 1:49 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hi,
> >
> > I have got lldb launch working fine on my macbook for sometime. But when
> I try the same code on Linux, it failed to emit any stopping events during
> initial launch.
> >
> > When I run the reproduce code(listed at the end), I got the following
> different results:
> >
> > The key difference is that Macbook will emit a stopped event which
> caused our IDE UI to enter break mode, while Linux violates this
> assumption. Is this a bug?
> >
> > ==Mac==
> > lldb_pythonpath:
> /Applications/Xcode.app/Contents/Developer/../SharedFrameworks/LLDB.framework/Resources/Python
> > Launch result: success
> >  Listening Thread ID: 4610625536
> > dbg> Target event: ModulesLoaded
> > Process event: StateChanged, Stopped
> > Stop reason: 5
> > dbg> bt
> > * thread #1: tid = 0x101f01d, 0x7fff6401a000 dyld`_dyld_start, stop
> reason = signal SIGSTOP
> >   * frame #0: 0x7fff6401a000 dyld`_dyld_start
> > ==Mac==
> >
> > ==Linux==
> > python linux_launch.py
> > find_lldb:  '/home/jeffreytan/project/llvm-bin/Debug+Asserts/lib/python2.7/site-packages/lldb/__init__.pyc'>
> > Launch result: success
> >  Listening Thread ID: 140316621375232
> > dbg> bt
> > * thread #1: tid = 2794520, 0x7f6165b7bb00, name = 'foo', stop
> reason = signal SIGSTOP
> >   * frame #0: 0x7f6165b7bb00
> > ==Linux==
> >
> > Repro main.py
> > # Should be first for LLDB package to be added to search path.
> > from find_lldb import lldb
> > import sys
> > import os
> > import time
> > from sys import stdin, stdout
> > from event_thread import LLDBListenerThread
> > import threading
> >
> >
> > def interctive_loop(debugger):
> > while (True):
> > stdout.write('dbg> ')
> > command = stdin.readline().rstrip()
> > if len(command) == 0:
> > continue
> > if command == 'q':
> > return
> > debugger.HandleCommand(command)
> >
> > def do_test():
> > debugger = lldb.SBDebugger.Create()
> > debugger.SetAsync(True)
> > executable_path =
> '~/Personal/compiler/CompilerConstruction/code/compiler'
> > target = debugger.CreateTargetWithFileAndArch(executable_path,
> lldb.LLDB_ARCH_DEFAULT)
> >
> > listener = lldb.SBListener('Event Listener')
> > error = lldb.SBError()
> > process = target.Launch (listener,
> >  None,  # argv
> >  None,  # envp
> >  None,  # stdin_path
> >  None,  # stdout_path
> >  None,  # stderr_path
> >  None,  # working directory
> >  0, # launch flags
> >  True, # Stop at entry
> >  error) # error
> > print 'Launch result: %s' % str(error)
> >
> > running_signal = threading.Event()
> > stopped_signal = threading.Event()
> > event_thread = LLDBListenerThread(debugger, running_signal,
> stopped_signal)
> > event_thread.start()
> >
> > interctive_loop(debugger)
> >
> > event_thread.should_quit = True
> > event_thread.join()
> >
> > lldb.SBDebugger.Destroy(debugger)
> > return debugger
> >
> > def main():
> > debugger = do_test()
> >
> > if __name__ == '__main__':
> > main()
> >
> > Event_thread
> > class LLDBListenerThread(Thread):
> > should_quit = False
> >
> > def __init__(self, debugger, running_signal=None,
> stopped_

[lldb-dev] Questions for module/symbol load/unload events

[Jeffrey Tan via lldb-dev]

Hi,

I am trying to listen for module/symbol load/unload events and display them
in output UI so that debugger users can have a basic clue what is debugger
busy doing while launching a big executable linking many shared libraries.

Questions:
1. I did not find an API to get current load/unload module during module
events. I was expecting some static API like lldb.SBModule(or
SBTarget).GetModuleFromEvent(SBEvent), but this does not exists. I tried to
treat current PC's module as loading module in module load/unload events.
But that does not work too(I think because process is not stopped in module
load/unload events). Do I miss something here?

2. Even though "image list" shows I have around 42 modules loaded in
process, I only got two module load events. Why is that?

3. Even though I added lldb.SBTarget.eBroadcastBitSymbolsLoaded, there is
no event of type eBroadcastBitSymbolsLoaded generated. Is it expected?
Apparently I have the symbols next to the binary.

This is tested on mac OSX lldb.

Jeffrey
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Questions for module/symbol load/unload events

[Jeffrey Tan via lldb-dev]

This is very useful, thanks for the info!

On Mon, Feb 29, 2016 at 10:36 AM, Jim Ingham  wrote:

>
> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi,
>
> I am trying to listen for module/symbol load/unload events and display
> them in output UI so that debugger users can have a basic clue what is
> debugger busy doing while launching a big executable linking many shared
> libraries.
>
> Questions:
> 1. I did not find an API to get current load/unload module during module
> events. I was expecting some static API like lldb.SBModule(or
> SBTarget).GetModuleFromEvent(SBEvent), but this does not exists. I tried to
> treat current PC's module as loading module in module load/unload events.
> But that does not work too(I think because process is not stopped in module
> load/unload events). Do I miss something here?
>
>
> From SBTarget.h:
>
> static uint32_t
> GetNumModulesFromEvent (const lldb::SBEvent &event);
>
> static lldb::SBModule
> GetModuleAtIndexFromEvent (const uint32_t idx, const lldb::SBEvent
> &event);
>
> Note, you can also cause the process to stop with modules are loaded with
> the setting:
>
> target.process.stop-on-sharedlibrary-events
>
> if that is more convenient for you.
>
>
> 2. Even though "image list" shows I have around 42 modules loaded in
> process, I only got two module load events. Why is that?
>
>
> On OS X the loader loads the closure of modules for whatever it is
> loading, and only stops and informs the debugger when this is all done.  So
> it is quite usual to see only a few load events even though many modules
> get loaded.
>
>
>
> 3. Even though I added lldb.SBTarget.eBroadcastBitSymbolsLoaded, there is
> no event of type eBroadcastBitSymbolsLoaded generated. Is it expected?
> Apparently I have the symbols next to the binary.
>
>
> That event gets sent when symbols are added to an already loaded module.
> It is so a UI will know to refresh the backtrace, local variables, source
> view, etc when code goes from having no symbols to having some symbols.
> Those actions are not needed if the library & its symbols get loaded
> simultaneously, so it isn’t sent in that case.
>
> Jim
>
>
>
> This is tested on mac OSX lldb.
>
> Jeffrey
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Questions for module/symbol load/unload events

[Jeffrey Tan via lldb-dev]

I see why I did not find them in the first place. These two APIs are not
listed in the official doc:
http://lldb.llvm.org/python_reference/index.html

Someone might want to add it.

Thanks
Jeffrey

On Mon, Feb 29, 2016 at 11:59 AM, Jeffrey Tan 
wrote:

> This is very useful, thanks for the info!
>
> On Mon, Feb 29, 2016 at 10:36 AM, Jim Ingham  wrote:
>
>>
>> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> Hi,
>>
>> I am trying to listen for module/symbol load/unload events and display
>> them in output UI so that debugger users can have a basic clue what is
>> debugger busy doing while launching a big executable linking many shared
>> libraries.
>>
>> Questions:
>> 1. I did not find an API to get current load/unload module during module
>> events. I was expecting some static API like lldb.SBModule(or
>> SBTarget).GetModuleFromEvent(SBEvent), but this does not exists. I tried to
>> treat current PC's module as loading module in module load/unload events.
>> But that does not work too(I think because process is not stopped in module
>> load/unload events). Do I miss something here?
>>
>>
>> From SBTarget.h:
>>
>> static uint32_t
>> GetNumModulesFromEvent (const lldb::SBEvent &event);
>>
>> static lldb::SBModule
>> GetModuleAtIndexFromEvent (const uint32_t idx, const lldb::SBEvent
>> &event);
>>
>> Note, you can also cause the process to stop with modules are loaded with
>> the setting:
>>
>> target.process.stop-on-sharedlibrary-events
>>
>> if that is more convenient for you.
>>
>>
>> 2. Even though "image list" shows I have around 42 modules loaded in
>> process, I only got two module load events. Why is that?
>>
>>
>> On OS X the loader loads the closure of modules for whatever it is
>> loading, and only stops and informs the debugger when this is all done.  So
>> it is quite usual to see only a few load events even though many modules
>> get loaded.
>>
>>
>>
>> 3. Even though I added lldb.SBTarget.eBroadcastBitSymbolsLoaded, there is
>> no event of type eBroadcastBitSymbolsLoaded generated. Is it expected?
>> Apparently I have the symbols next to the binary.
>>
>>
>> That event gets sent when symbols are added to an already loaded module.
>> It is so a UI will know to refresh the backtrace, local variables, source
>> view, etc when code goes from having no symbols to having some symbols.
>> Those actions are not needed if the library & its symbols get loaded
>> simultaneously, so it isn’t sent in that case.
>>
>> Jim
>>
>>
>>
>> This is tested on mac OSX lldb.
>>
>> Jeffrey
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Questions for module/symbol load/unload events

[Jeffrey Tan via lldb-dev]

Greg, missed your reply. Yeah, the problem is that I only looked at the
python API(which is what I am using) doc which does not contain these APIs.

On Mon, Feb 29, 2016 at 12:43 PM, Greg Clayton  wrote:

> In general where you see the event bits defined like SBTarget.h for your
> case, the class that contains the event bit definitions:
>
> class SBTarget
> {
> public:
> //--
> // Broadcaster bits.
> //--
> enum
> {
> eBroadcastBitBreakpointChanged  = (1 << 0),
> eBroadcastBitModulesLoaded  = (1 << 1),
> eBroadcastBitModulesUnloaded= (1 << 2),
> eBroadcastBitWatchpointChanged  = (1 << 3),
> eBroadcastBitSymbolsLoaded  = (1 << 4)
> };
> ...
>
>
> Also contains all of the static functions that can extract data from those
> events:
>
>
> class SBTarget
> {
> public:
> ...
> static bool
> EventIsTargetEvent (const lldb::SBEvent &event);
>
> static lldb::SBTarget
> GetTargetFromEvent (const lldb::SBEvent &event);
>
> static uint32_t
> GetNumModulesFromEvent (const lldb::SBEvent &event);
>
> static lldb::SBModule
>     GetModuleAtIndexFromEvent (const uint32_t idx, const lldb::SBEvent
> &event);
>
>
> Greg Clayton
>
>
>
> > On Feb 29, 2016, at 11:59 AM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > This is very useful, thanks for the info!
> >
> > On Mon, Feb 29, 2016 at 10:36 AM, Jim Ingham  wrote:
> >
> >> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>
> >> Hi,
> >>
> >> I am trying to listen for module/symbol load/unload events and display
> them in output UI so that debugger users can have a basic clue what is
> debugger busy doing while launching a big executable linking many shared
> libraries.
> >>
> >> Questions:
> >> 1. I did not find an API to get current load/unload module during
> module events. I was expecting some static API like lldb.SBModule(or
> SBTarget).GetModuleFromEvent(SBEvent), but this does not exists. I tried to
> treat current PC's module as loading module in module load/unload events.
> But that does not work too(I think because process is not stopped in module
> load/unload events). Do I miss something here?
> >
> > From SBTarget.h:
> >
> > static uint32_t
> > GetNumModulesFromEvent (const lldb::SBEvent &event);
> >
> > static lldb::SBModule
> > GetModuleAtIndexFromEvent (const uint32_t idx, const lldb::SBEvent
> &event);
> >
> > Note, you can also cause the process to stop with modules are loaded
> with the setting:
> >
> > target.process.stop-on-sharedlibrary-events
> >
> > if that is more convenient for you.
> >
> >>
> >> 2. Even though "image list" shows I have around 42 modules loaded in
> process, I only got two module load events. Why is that?
> >
> > On OS X the loader loads the closure of modules for whatever it is
> loading, and only stops and informs the debugger when this is all done.  So
> it is quite usual to see only a few load events even though many modules
> get loaded.
> >
> >
> >>
> >> 3. Even though I added lldb.SBTarget.eBroadcastBitSymbolsLoaded, there
> is no event of type eBroadcastBitSymbolsLoaded generated. Is it expected?
> Apparently I have the symbols next to the binary.
> >
> > That event gets sent when symbols are added to an already loaded
> module.  It is so a UI will know to refresh the backtrace, local variables,
> source view, etc when code goes from having no symbols to having some
> symbols.  Those actions are not needed if the library & its symbols get
> loaded simultaneously, so it isn’t sent in that case.
> >
> > Jim
> >
> >
> >>
> >> This is tested on mac OSX lldb.
> >>
> >> Jeffrey
> >> ___
> >> lldb-dev mailing list
> >> lldb-dev@lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Questions for module/symbol load/unload events

[Jeffrey Tan via lldb-dev]

Btw: I did not find an API to retrieve the load address of the SBModule?
This seems to be weird to me, did I miss anything?


On Mon, Feb 29, 2016 at 1:34 PM, Jeffrey Tan 
wrote:

> I see why I did not find them in the first place. These two APIs are not
> listed in the official doc:
> http://lldb.llvm.org/python_reference/index.html
>
> Someone might want to add it.
>
> Thanks
> Jeffrey
>
> On Mon, Feb 29, 2016 at 11:59 AM, Jeffrey Tan 
> wrote:
>
>> This is very useful, thanks for the info!
>>
>> On Mon, Feb 29, 2016 at 10:36 AM, Jim Ingham  wrote:
>>
>>>
>>> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
>>> Hi,
>>>
>>> I am trying to listen for module/symbol load/unload events and display
>>> them in output UI so that debugger users can have a basic clue what is
>>> debugger busy doing while launching a big executable linking many shared
>>> libraries.
>>>
>>> Questions:
>>> 1. I did not find an API to get current load/unload module during module
>>> events. I was expecting some static API like lldb.SBModule(or
>>> SBTarget).GetModuleFromEvent(SBEvent), but this does not exists. I tried to
>>> treat current PC's module as loading module in module load/unload events.
>>> But that does not work too(I think because process is not stopped in module
>>> load/unload events). Do I miss something here?
>>>
>>>
>>> From SBTarget.h:
>>>
>>> static uint32_t
>>> GetNumModulesFromEvent (const lldb::SBEvent &event);
>>>
>>> static lldb::SBModule
>>> GetModuleAtIndexFromEvent (const uint32_t idx, const lldb::SBEvent
>>> &event);
>>>
>>> Note, you can also cause the process to stop with modules are loaded
>>> with the setting:
>>>
>>> target.process.stop-on-sharedlibrary-events
>>>
>>> if that is more convenient for you.
>>>
>>>
>>> 2. Even though "image list" shows I have around 42 modules loaded in
>>> process, I only got two module load events. Why is that?
>>>
>>>
>>> On OS X the loader loads the closure of modules for whatever it is
>>> loading, and only stops and informs the debugger when this is all done.  So
>>> it is quite usual to see only a few load events even though many modules
>>> get loaded.
>>>
>>>
>>>
>>> 3. Even though I added lldb.SBTarget.eBroadcastBitSymbolsLoaded, there
>>> is no event of type eBroadcastBitSymbolsLoaded generated. Is it expected?
>>> Apparently I have the symbols next to the binary.
>>>
>>>
>>> That event gets sent when symbols are added to an already loaded
>>> module.  It is so a UI will know to refresh the backtrace, local variables,
>>> source view, etc when code goes from having no symbols to having some
>>> symbols.  Those actions are not needed if the library & its symbols get
>>> loaded simultaneously, so it isn’t sent in that case.
>>>
>>> Jim
>>>
>>>
>>>
>>> This is tested on mac OSX lldb.
>>>
>>> Jeffrey
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>>
>>>
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Questions for module/symbol load/unload events

[Jeffrey Tan via lldb-dev]

My assumption is that different sections of the binary will be mapped
continuously in memory; and the first section(which should be a header
section for the binary) will stands for the base address of the whole
module.
Is this assumption not true for all platforms? Basically, I would like to
show the memory range of the whole module, instead of just text section, so
that if a debugger user got a magic address, he can quickly examine the
image list to see which binary this address falls into. I guess I can
calculate and combine all sections, but it is a bit cumbersome to do.

On Mon, Feb 29, 2016 at 4:02 PM, Greg Clayton  wrote:

> As Jim said there really isn't just one address per module. You will want
> to display the address of each of the sections for a module under that
> module. So something like:
>
>
> a.out
>   |- .text @ 0x1
>   |- .data @ 0x2
>   \- .bss  @ 0x3
>
>
> > On Feb 29, 2016, at 2:02 PM, Jeffrey Tan 
> wrote:
> >
> > Btw: I did not find an API to retrieve the load address of the SBModule?
> This seems to be weird to me, did I miss anything?
> >
> >
> > On Mon, Feb 29, 2016 at 1:34 PM, Jeffrey Tan 
> wrote:
> > I see why I did not find them in the first place. These two APIs are not
> listed in the official doc:
> > http://lldb.llvm.org/python_reference/index.html
> >
> > Someone might want to add it.
> >
> > Thanks
> > Jeffrey
> >
> > On Mon, Feb 29, 2016 at 11:59 AM, Jeffrey Tan 
> wrote:
> > This is very useful, thanks for the info!
> >
> > On Mon, Feb 29, 2016 at 10:36 AM, Jim Ingham  wrote:
> >
> >> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>
> >> Hi,
> >>
> >> I am trying to listen for module/symbol load/unload events and display
> them in output UI so that debugger users can have a basic clue what is
> debugger busy doing while launching a big executable linking many shared
> libraries.
> >>
> >> Questions:
> >> 1. I did not find an API to get current load/unload module during
> module events. I was expecting some static API like lldb.SBModule(or
> SBTarget).GetModuleFromEvent(SBEvent), but this does not exists. I tried to
> treat current PC's module as loading module in module load/unload events.
> But that does not work too(I think because process is not stopped in module
> load/unload events). Do I miss something here?
> >
> > From SBTarget.h:
> >
> > static uint32_t
> > GetNumModulesFromEvent (const lldb::SBEvent &event);
> >
> > static lldb::SBModule
> > GetModuleAtIndexFromEvent (const uint32_t idx, const lldb::SBEvent
> &event);
> >
> > Note, you can also cause the process to stop with modules are loaded
> with the setting:
> >
> > target.process.stop-on-sharedlibrary-events
> >
> > if that is more convenient for you.
> >
> >>
> >> 2. Even though "image list" shows I have around 42 modules loaded in
> process, I only got two module load events. Why is that?
> >
> > On OS X the loader loads the closure of modules for whatever it is
> loading, and only stops and informs the debugger when this is all done.  So
> it is quite usual to see only a few load events even though many modules
> get loaded.
> >
> >
> >>
> >> 3. Even though I added lldb.SBTarget.eBroadcastBitSymbolsLoaded, there
> is no event of type eBroadcastBitSymbolsLoaded generated. Is it expected?
> Apparently I have the symbols next to the binary.
> >
> > That event gets sent when symbols are added to an already loaded
> module.  It is so a UI will know to refresh the backtrace, local variables,
> source view, etc when code goes from having no symbols to having some
> symbols.  Those actions are not needed if the library & its symbols get
> loaded simultaneously, so it isn’t sent in that case.
> >
> > Jim
> >
> >
> >>
> >> This is tested on mac OSX lldb.
> >>
> >> Jeffrey
> >> ___
> >> lldb-dev mailing list
> >> lldb-dev@lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> >
> >
> >
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] How to set source line breakpoint using BreakpointCreateByLocation?

[Jeffrey Tan via lldb-dev]

/Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m:21
>>> >   address = 0x000103deae42
>>> >   resolved = true
>>> >   hit count = 0
>>> >
>>>
>>> Wow that is a lot of redundant 's. You should fix your build system
>>> to not do this for one, but I agree we need to deal with this.
>>>
>>> You can modify the following function:
>>>
>>> void
>>> FileSpec::RemoveBackupDots (const ConstString &input_const_str,
>>> ConstString &result_const_str);
>>>
>>> To remove the redundant slashes and it might make things work. The thing
>>> that really worries me is that you still have a relative location in your
>>> sources:
>>>
>>>
>>> "./Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m:21"
>>>
>>>
>>> This should have been resolved from the DWARF using DW_AT_comp_dir. What
>>> should happen is your DWARF should have a compile unit like:
>>>
>>>
>>> 0x000b: DW_TAG_compile_unit [1] *
>>> DW_AT_producer( "Apple LLVM version 7.x.x" )
>>> DW_AT_language( DW_LANG_ObjC )
>>> DW_AT_name(
>>> "./Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m" )
>>> DW_AT_stmt_list( 0x )
>>> DW_AT_comp_dir( "/tmp/build/foo/bar" )
>>> DW_AT_low_pc( 0x00010b50 )
>>> DW_AT_high_pc( 0x00010e62 )
>>>
>>>
>>> So if the DW_AT_name of your compile unit is relative, we should have a
>>> DW_AT_comp_dir that is absolute. Put the two together and we should have a
>>> complete path that works.
>>>
>>> Can you send me your ELF file that contains the DWARF so I can look at
>>> it?
>>>
>>> > I think we should fix this full path matching issue. It is totally
>>> reasonable for debugger user to move source file from build location to
>>> another place. Also, this needs to be supported for source server scenario.
>>> As long as the source file's checksum matches what recorded in symbol file
>>> we should match it.
>>> >
>>> > I still need to figure out why
>>> "self.debugger.GetSelectedTarget().BreakpointCreateByLocation("EATAnimatedView.m",
>>> line)" not working issue. The callstack seems to indicate I passed wrong
>>> number of arguments into it.
>>>
>>> This might be a swig type map issue where "line" in the python is a long
>>> and we don't know how to convert it to be passed to a uint32_t. We have
>>> seen such issues if the past where if you variable is a long, integer or
>>> other, it might not convert to uint32_t correctly...
>>>
>>>
>>> >
>>> > Jeffrey
>>> >
>>> > On Thu, Oct 8, 2015 at 9:46 AM, Greg Clayton 
>>> wrote:
>>> > > On Oct 7, 2015, at 8:31 PM, Jeffrey Tan via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>> > >
>>> > > Hi,
>>> > >
>>> > > I am writing a python script to set source line breakpoint in ObjC
>>> on Mac OSX. But
>>> self.debugger.GetSelectedTarget().BreakpointCreateByLocation("EATAnimatedView.m",
>>> line) always fail. Any ideas?
>>> >
>>> > As long as you have a selected target, this should work as long as you
>>> have debug info that matches.
>>> > >
>>> > > Also, can I use full path instead of file basename?
>>> >
>>> > Yes you can, but it must match exactly if you use the full path.
>>> >
>>> > > In lldb, I found "b
>>> /Users/jeffreytan/fbsource/fbobjc/Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m:21"
>>> will fail to bind but "b EATAnimatedView.m:21" will succeed.
>>> >
>>> > This is usually because you have a makefile build system that is
>>> creating debug info that doesn't contain a path that matches. When you
>>> launch a compiler, it can often end up with different paths than what you
>>> think you have. So set the breakpoint by basename first, then do:
>>&

Re: [lldb-dev] How to set source line breakpoint using BreakpointCreateByLocation?

[Jeffrey Tan via lldb-dev]

ANG_ObjC )
> > DW_AT_name(
> "./Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m" )
> > DW_AT_stmt_list( 0x )
> > DW_AT_comp_dir( "/tmp/build/foo/bar" )
> > DW_AT_low_pc( 0x00010b50 )
> > DW_AT_high_pc( 0x00010e62 )
> >
> >
> > So if the DW_AT_name of your compile unit is relative, we should have a
> DW_AT_comp_dir that is absolute. Put the two together and we should have a
> complete path that works.
> >
> > Can you send me your ELF file that contains the DWARF so I can look at
> it?
> >
> > > I think we should fix this full path matching issue. It is totally
> reasonable for debugger user to move source file from build location to
> another place. Also, this needs to be supported for source server scenario.
> As long as the source file's checksum matches what recorded in symbol file
> we should match it.
> > >
> > > I still need to figure out why
> "self.debugger.GetSelectedTarget().BreakpointCreateByLocation("EATAnimatedView.m",
> line)" not working issue. The callstack seems to indicate I passed wrong
> number of arguments into it.
> >
> > This might be a swig type map issue where "line" in the python is a long
> and we don't know how to convert it to be passed to a uint32_t. We have
> seen such issues if the past where if you variable is a long, integer or
> other, it might not convert to uint32_t correctly...
> >
> >
> > >
> > > Jeffrey
> > >
> > > On Thu, Oct 8, 2015 at 9:46 AM, Greg Clayton 
> wrote:
> > > > On Oct 7, 2015, at 8:31 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I am writing a python script to set source line breakpoint in ObjC
> on Mac OSX. But
> self.debugger.GetSelectedTarget().BreakpointCreateByLocation("EATAnimatedView.m",
> line) always fail. Any ideas?
> > >
> > > As long as you have a selected target, this should work as long as you
> have debug info that matches.
> > > >
> > > > Also, can I use full path instead of file basename?
> > >
> > > Yes you can, but it must match exactly if you use the full path.
> > >
> > > > In lldb, I found "b
> /Users/jeffreytan/fbsource/fbobjc/Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m:21"
> will fail to bind but "b EATAnimatedView.m:21" will succeed.
> > >
> > > This is usually because you have a makefile build system that is
> creating debug info that doesn't contain a path that matches. When you
> launch a compiler, it can often end up with different paths than what you
> think you have. So set the breakpoint by basename first, then do:
> > >
> > > (lldb) b main.c:12
> > > Breakpoint 1: where = a.out`main + 70 at main.c:12, address =
> 0x00010b96
> > > (lldb) breakpoint list --verbose
> > > Current breakpoints:
> > > 1: file = 'main.c', line = 12
> > > 1.1:
> > >   module = /Volumes/work/gclayton/Documents/src/args/a.out
> > >   compile unit = main.c
> > >   function = main
> > >   location = /Volumes/work/gclayton/Documents/src/args/main.c:12
> > >   address = a.out[0x00010b96]
> > >   resolved = false
> > >   hit count = 0
> > >
> > >
> > > You will see the full path to your source file in the "location"
> value. You will probably notice that the path is different. We try to take
> care of removing and extra "../useless_dir" things from the paths and still
> make things match, but you might have a case that we aren't handling. Let
> me know what you see when you set the breakpoint by basename.
> > >
> > >
> > > > Traceback (most recent call last):
> > > >   File
> "/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/chromedebugger.py",
> line 69, in _generate_response
> > > > params=message.get('params', {}),
> > > >   File
> "/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/handler.py",
> line 42, in handle
> > > > return self._domains[domain_name].handle(method_name, params)
> > > >   File
> "/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/handler.py",
> line 106, in handle
> > > > return self._handlers[method](params)
> > > >   File
> "/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/handler.py",
> line 56, in _handler_wrapper
> > > > ret = func(self, params)
> > > >   File
> "/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/debugger.py",
> line 248, in setBreakpointByUrl
> > > > int(params['lineNumber']) + 1)
> > > >   File
> "/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/debugger.py",
> line 283, in _set_breakpoint_by_filespec
> > > > breakpoint =
> self.debugger.GetSelectedTarget().BreakpointCreateByLocation(filespec, line)
> > > >   File
> "/Applications/Xcode.app/Contents/Developer/../SharedFrameworks/LLDB.framework/Resources/Python/lldb/__init__.py",
> line 8650, in BreakpointCreateByLocation
> > > > return _lldb.SBTarget_BreakpointCreateByLocation(self, *args)
> > > > NotImplementedError: Wrong number of arguments for overloaded
> function 'SBTarget_BreakpointCreateByLocation'.
> > > >   Possible C/C++ prototypes are:
> > > > BreakpointCreateByLocation(lldb::SBTarget *,char const
> *,uint32_t)
> > > > BreakpointCreateByLocation(lldb::SBTarget *,lldb::SBFileSpec
> const &,uint32_t)
> > > > ___
> > > > lldb-dev mailing list
> > > > lldb-dev@lists.llvm.org
> > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> > >
> > >
> >
> >
> >
> >
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] How to set source line breakpoint using BreakpointCreateByLocation?

[Jeffrey Tan via lldb-dev]

I agree we need to deal with this.
> > >
> > > You can modify the following function:
> > >
> > > void
> > > FileSpec::RemoveBackupDots (const ConstString &input_const_str,
> ConstString &result_const_str);
> > >
> > > To remove the redundant slashes and it might make things work. The
> thing that really worries me is that you still have a relative location in
> your sources:
> > >
> > >
> "./Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m:21"
> > >
> > >
> > > This should have been resolved from the DWARF using DW_AT_comp_dir.
> What should happen is your DWARF should have a compile unit like:
> > >
> > >
> > > 0x000b: DW_TAG_compile_unit [1] *
> > > DW_AT_producer( "Apple LLVM version 7.x.x" )
> > > DW_AT_language( DW_LANG_ObjC )
> > > DW_AT_name(
> "./Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m" )
> > > DW_AT_stmt_list( 0x )
> > > DW_AT_comp_dir( "/tmp/build/foo/bar" )
> > > DW_AT_low_pc( 0x00010b50 )
> > > DW_AT_high_pc( 0x00010e62 )
> > >
> > >
> > > So if the DW_AT_name of your compile unit is relative, we should have
> a DW_AT_comp_dir that is absolute. Put the two together and we should have
> a complete path that works.
> > >
> > > Can you send me your ELF file that contains the DWARF so I can look at
> it?
> > >
> > > > I think we should fix this full path matching issue. It is totally
> reasonable for debugger user to move source file from build location to
> another place. Also, this needs to be supported for source server scenario.
> As long as the source file's checksum matches what recorded in symbol file
> we should match it.
> > > >
> > > > I still need to figure out why
> "self.debugger.GetSelectedTarget().BreakpointCreateByLocation("EATAnimatedView.m",
> line)" not working issue. The callstack seems to indicate I passed wrong
> number of arguments into it.
> > >
> > > This might be a swig type map issue where "line" in the python is a
> long and we don't know how to convert it to be passed to a uint32_t. We
> have seen such issues if the past where if you variable is a long, integer
> or other, it might not convert to uint32_t correctly...
> > >
> > >
> > > >
> > > > Jeffrey
> > > >
> > > > On Thu, Oct 8, 2015 at 9:46 AM, Greg Clayton 
> wrote:
> > > > > On Oct 7, 2015, at 8:31 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I am writing a python script to set source line breakpoint in ObjC
> on Mac OSX. But
> self.debugger.GetSelectedTarget().BreakpointCreateByLocation("EATAnimatedView.m",
> line) always fail. Any ideas?
> > > >
> > > > As long as you have a selected target, this should work as long as
> you have debug info that matches.
> > > > >
> > > > > Also, can I use full path instead of file basename?
> > > >
> > > > Yes you can, but it must match exactly if you use the full path.
> > > >
> > > > > In lldb, I found "b
> /Users/jeffreytan/fbsource/fbobjc/Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m:21"
> will fail to bind but "b EATAnimatedView.m:21" will succeed.
> > > >
> > > > This is usually because you have a makefile build system that is
> creating debug info that doesn't contain a path that matches. When you
> launch a compiler, it can often end up with different paths than what you
> think you have. So set the breakpoint by basename first, then do:
> > > >
> > > > (lldb) b main.c:12
> > > > Breakpoint 1: where = a.out`main + 70 at main.c:12, address =
> 0x00010b96
> > > > (lldb) breakpoint list --verbose
> > > > Current breakpoints:
> > > > 1: file = 'main.c', line = 12
> > > > 1.1:
> > > >   module = /Volumes/work/gclayton/Documents/src/args/a.out
> > > >   compile unit = main.c
> > > >   function = main
>

Re: [lldb-dev] How to set source line breakpoint using BreakpointCreateByLocation?

[Jeffrey Tan via lldb-dev]

  lldb_pythonpath = os.path.join(
> > > > developer_dir.strip(),
> '../SharedFrameworks/LLDB.framework/Resources/Python')
> > > > sys.path.append(lldb_pythonpath)
> > > >
> > > > For the weird long path issue, I will follow-up with our build team,
> but definitely needs to resolve the BreakpointCreateByLocation() can't be
> called issue first.
> > > >
> > > > Thanks for any help!
> > > > Jeffrey
> > > >
> > > > On Thu, Oct 8, 2015 at 10:46 AM, Greg Clayton 
> wrote:
> > > >
> > > > > On Oct 8, 2015, at 10:25 AM, Jeffrey Tan 
> wrote:
> > > > >
> > > > > Thanks Greg. Here is the info:
> > > > > (lldb) br list --verbose
> > > > > Current breakpoints:
> > > > > 1: file = 'EATAnimatedView.m', line = 21
> > > > > 1.1:
> > > > >   module =
> /Users/jeffreytan/Library/Developer/CoreSimulator/Devices/12E85C41-A74F-45E1-8440-E7D08D8EB1FA/data/Containers/Bundle/Application/3BA10AF8-9B18-4FD8-8C76-EA25DE2F37E6/MPKEats.app/MPKEats
> > > > >   compile unit = EATAnimatedView.m
> > > > >   function = -[EATAnimatedView
> initWithFrame:imageNames:animationDuration:repeatCount:touchEnabled:]
> > > > >   location =
> ./Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m:21
> > > > >   address = 0x000103deae42
> > > > >   resolved = true
> > > > >   hit count = 0
> > > > >
> > > >
> > > > Wow that is a lot of redundant 's. You should fix your build
> system to not do this for one, but I agree we need to deal with this.
> > > >
> > > > You can modify the following function:
> > > >
> > > > void
> > > > FileSpec::RemoveBackupDots (const ConstString &input_const_str,
> ConstString &result_const_str);
> > > >
> > > > To remove the redundant slashes and it might make things work. The
> thing that really worries me is that you still have a relative location in
> your sources:
> > > >
> > > >
> "./Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m:21"
> > > >
> > > >
> > > > This should have been resolved from the DWARF using DW_AT_comp_dir.
> What should happen is your DWARF should have a compile unit like:
> > > >
> > > >
> > > > 0x000b: DW_TAG_compile_unit [1] *
> > > > DW_AT_producer( "Apple LLVM version 7.x.x" )
> > > > DW_AT_language( DW_LANG_ObjC )
> > > > DW_AT_name(
> "./Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m" )
> > > > DW_AT_stmt_list( 0x )
> > > > DW_AT_comp_dir( "/tmp/build/foo/bar" )
> > > > DW_AT_low_pc( 0x00010b50 )
> > > > DW_AT_high_pc( 0x00010e62 )
> > > >
> > > >
> > > > So if the DW_AT_name of your compile unit is relative, we should
> have a DW_AT_comp_dir that is absolute. Put the two together and we should
> have a complete path that works.
> > > >
> > > > Can you send me your ELF file that contains the DWARF so I can look
> at it?
> > > >
> > > > > I think we should fix this full path matching issue. It is totally
> reasonable for debugger user to move source file from build location to
> another place. Also, this needs to be supported for source server scenario.
> As long as the source file's checksum matches what recorded in symbol file
> we should match it.
> > > > >
> > > > > I still need to figure out why
> "self.debugger.GetSelectedTarget().BreakpointCreateByLocation("EATAnimatedView.m",
> line)" not working issue. The callstack seems to indicate I passed wrong
> number of arguments into it.
> > > >
> > > > This might be a swig type map issue where "line" in the python is a
> long and we don

[lldb-dev] How to get the error message while creating an invalid target?

[Jeffrey Tan via lldb-dev]

Hi,

In lldb, when I try to "target create [invalid_target]", I got some
meaningful error message like:
error: 'XXX' doesn't contain any 'host' platform architectures: x86_64h,
x86_64, i386

What is the python API to get this from? I tried to check
SBTarget.IsValid() and then use
SBTarget.GetDescription(eDescriptionLevelVerbose), but that does not return
the error message.

Thanks
Jeffrey
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] How to get the error message while creating an invalid target?

[Jeffrey Tan via lldb-dev]

Ah, I used CreateTargetWithFileAndArch() and missed this one. Feeling
embarrassed... Thank you!

On Wed, Mar 9, 2016 at 10:10 AM, Greg Clayton  wrote:

> The SBDebugger::CreateTarget() call take an "SBError &error" as the last
> argument. The error will contain any error message:
>
> lldb::SBTarget
> CreateTarget (const char *filename,
>   const char *target_triple,
>   const char *platform_name,
>   bool add_dependent_modules,
>   lldb::SBError& error);
>
>
>
> This function is the one that should be used. Any of the "const char *"
> arguments can be NULL. But typically you want to specify at least the
> filename. The triple is only really needed if you are debugging files that
> have more than one architecture or if the file you are debugging doesn't
> completely specify what you want to debug. The triple can be "x86_64" or
> more specific like "x86_64-apple-ios". The platform name only needs to be
> specified if your executable file (ELF file, mach-o file, or other exe
> format) doesn't have enough information inside of it to extract the triple
> from the object file. ELF has very sparse information inside of it to help
> us identify what platform it can/should be used for. You will know if you
> need to specify the platform if LLDB gets it wrong. To see what happens,
> try things out from the command line:
>
>
> (lldb) target create /tmp/a.out
> (lldb) target list
> Current targets:
> * target #0: /tmp/a.out ( arch=x86_64-apple-macosx, platform=host )
>
> We see that the "host" platform was auto selected and the architecture was
> extracted from the executable as "x86_64-apple-macosx".
>
> To see a list of platform names you can do:
>
> (lldb) platform select 
> Available completions:
> remote-freebsd
> remote-linux
> remote-netbsd
> remote-windows
> kalimba
> remote-android
> remote-ios
> remote-macosx
> ios-simulator
> darwin-kernel
> tvos-simulator
> watchos-simulator
> remote-tvos
> remote-watchos
> remote-gdb-server
>
> So if you have an iOS binary that was targeting a device (not a
> simulator), you could create your target with:
>
> lldb::SBError error;
> lldb::SBTarget target = debugger.CreateTarget("/tmp/a.out",
> "armv7-apple-ios", "remote-ios", false, error);
>
>
> > On Mar 8, 2016, at 5:22 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hi,
> >
> > In lldb, when I try to "target create [invalid_target]", I got some
> meaningful error message like:
> > error: 'XXX' doesn't contain any 'host' platform architectures: x86_64h,
> x86_64, i386
> >
> > What is the python API to get this from? I tried to check
> SBTarget.IsValid() and then use
> SBTarget.GetDescription(eDescriptionLevelVerbose), but that does not return
> the error message.
> >
> > Thanks
> > Jeffrey
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Better error message for attaching to a process already being debugged

[Jeffrey Tan via lldb-dev]

Hi,

My colleague is trying to use our lldb IDE attaching to app run/build from
Xcode which failed. I can reproduce this with lldb console:

jeffreytan-mbp:$ ps aux | grep iOSApp
jeffreytan  61816   0.0  0.0  2432772676 s002  S+3:00PM
0:00.00 grep iOSApp
jeffreytan  61806   0.0  0.2  2721120  38600   ??  SXs   3:00PM
0:00.24
/Users/jeffreytan/Library/Developer/CoreSimulator/Devices/EF17E202-3981-4DB0-87C9-2A9345C1E713/data/Containers/Bundle/Application/CAEBA7D7-D284-4489-8A53-A88E56F9BB04/iOSAppTest.app/iOSAppTest
jeffreytan-mbp:$ lldb -p 61806
(lldb) process attach --pid 61806
*error: attach failed: attach failed: unable to attach*

My theory is:
1. Xcode does not have the concept of run without debugger and run under
debugger, so it always run app with debugger enabled.(Is this true?)
2. And you can't have two native debuggers debugging the same process on
Mac(this is true on Windows, is it true for Mac or Linux?)

If both are true, can we report meaningful message like "inferior is
already being debugged" or something similar instead of the generic error
message like "*attach failed: unable to attach*"?

Btw: I found I can still use gdb to attach to the process(with a permission
elevation dialog pop-up) and see the callstack. How does gdb do that?

Jeffrey
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Better error message for attaching to a process already being debugged

[Jeffrey Tan via lldb-dev]

Hi Greg, I am using the lldb(/usr/bin/lldb) installed by Xcode not
self-built one. For example, I can use lldb to attach to chrome without any
problem. And I can see the debugserver it uses is from
"/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver".
Do I still need to sign it?
Only the app launched from Xcode IDE can't be attached from this lldb.

On Wed, Mar 9, 2016 at 3:08 PM, Greg Clayton  wrote:

> Did you follow the instructions and you have made your "lldb_codesign"
> code signing certificate?:
>
> svn cat http://llvm.org/svn/llvm-project/lldb/trunk/docs/code-signing.txt
>
> If you don't do this, your debugserver won't have the ability to debug
> anything. If you don't want to do this, you can remove the "debugserver"
> binary from your LLDB.framework that you built and are running with, and
> then we will fall back to using the one that is installed inside
> /Applications/Xcode.app as that one is Apple code signed.
>
> Greg
>
> > On Mar 9, 2016, at 3:04 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hi,
> >
> > My colleague is trying to use our lldb IDE attaching to app run/build
> from Xcode which failed. I can reproduce this with lldb console:
> >
> > jeffreytan-mbp:$ ps aux | grep iOSApp
> > jeffreytan  61816   0.0  0.0  2432772676 s002  S+3:00PM
>  0:00.00 grep iOSApp
> > jeffreytan  61806   0.0  0.2  2721120  38600   ??  SXs   3:00PM
>  0:00.24
> /Users/jeffreytan/Library/Developer/CoreSimulator/Devices/EF17E202-3981-4DB0-87C9-2A9345C1E713/data/Containers/Bundle/Application/CAEBA7D7-D284-4489-8A53-A88E56F9BB04/iOSAppTest.app/iOSAppTest
> > jeffreytan-mbp:$ lldb -p 61806
> > (lldb) process attach --pid 61806
> > error: attach failed: attach failed: unable to attach
> >
> > My theory is:
> > 1. Xcode does not have the concept of run without debugger and run under
> debugger, so it always run app with debugger enabled.(Is this true?)
> > 2. And you can't have two native debuggers debugging the same process on
> Mac(this is true on Windows, is it true for Mac or Linux?)
> >
> > If both are true, can we report meaningful message like "inferior is
> already being debugged" or something similar instead of the generic error
> message like "attach failed: unable to attach"?
> >
> > Btw: I found I can still use gdb to attach to the process(with a
> permission elevation dialog pop-up) and see the callstack. How does gdb do
> that?
> >
> > Jeffrey
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Better error message for attaching to a process already being debugged

[Jeffrey Tan via lldb-dev]

Thanks for the info Jim. That answers my questions. I will file a bug for
lldb error message.

On Wed, Mar 9, 2016 at 5:57 PM, Jim Ingham  wrote:

>
> > On Mar 9, 2016, at 3:04 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hi,
> >
> > My colleague is trying to use our lldb IDE attaching to app run/build
> from Xcode which failed. I can reproduce this with lldb console:
> >
> > jeffreytan-mbp:$ ps aux | grep iOSApp
> > jeffreytan  61816   0.0  0.0  2432772676 s002  S+3:00PM
>  0:00.00 grep iOSApp
> > jeffreytan  61806   0.0  0.2  2721120  38600   ??  SXs   3:00PM
>  0:00.24
> /Users/jeffreytan/Library/Developer/CoreSimulator/Devices/EF17E202-3981-4DB0-87C9-2A9345C1E713/data/Containers/Bundle/Application/CAEBA7D7-D284-4489-8A53-A88E56F9BB04/iOSAppTest.app/iOSAppTest
> > jeffreytan-mbp:$ lldb -p 61806
> > (lldb) process attach --pid 61806
> > error: attach failed: attach failed: unable to attach
> >
> > My theory is:
> > 1. Xcode does not have the concept of run without debugger and run under
> debugger, so it always run app with debugger enabled.(Is this true?)
>
> That is not true.  In the Run Scheme, uncheck the "Debug Executable"
> checkbox.  But running with the debugger is the default.
>
> Note, an X in the status field for ps means the app is being debugged.  So
> in this case, the app you were trying to attach to WAS already being
> debugged.
>
> > 2. And you can't have two native debuggers debugging the same process on
> Mac(this is true on Windows, is it true for Mac or Linux?)
>
> That is true for Mac, and in general for ptrace based debugging.  I don't
> know much about procfs.
>
> >
> > If both are true, can we report meaningful message like "inferior is
> already being debugged" or something similar instead of the generic error
> message like "attach failed: unable to attach"?
>
> That should be possible, there's code to eliminate already debugged
> processes in the "Attach to process by name" functionality.  So if you
> specify a PID and the attach fails, we could check after the fact and see
> if it is already being traced.  Please file a bug for this, and/or take a
> whack at fixing it if you feel like it.
>
> >
> > Btw: I found I can still use gdb to attach to the process(with a
> permission elevation dialog pop-up) and see the callstack. How does gdb do
> that?
>
> I haven't looked at the FSF gdb OS X support for years, so I can't really
> comment on it.  But it is not possible to ptrace something that is already
> ptraced, so if gdb is still doing it this way, then it should also fail.
> Maybe it is only getting the mach task and exception ports and debugging
> just with them?  You can have multiple readers for the task port, and you
> can steal the exception port from someone else.  But if it did that, the
> other debugger should stop working.
>
> Jim
>
>
> >
> > Jeffrey
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] How to attach process under root/different user account?

[Jeffrey Tan via lldb-dev]

Hi,

As the title said, what is the recommended way to attach a process under
different user account?

On Mac OS, when I try to use python binding to attach a root process, I got
a dialog saying "python is trying to take control of a root process ...".
After inputing password into the dialog, I got failure:
"Problems with launching via XPC. XPC error: Connection interrupted"

For Linux scenario, our IDE runs on MacOS, while using a RPC framework
talking to a IDE server on Linux devserver. This IDE server will use lldb
python binding to attach target process on Linux.
Is there any good way to attach root process on Linux devserver without
running IDE server under root account?

I guess I may need a UI/channel to gather user credential and elevate lldb
python binding process in some way. But a bit vague in this part. Thanks
for any input!

Jeffrey
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Weird stop stack while hitting breakpoint

[Jeffrey Tan via lldb-dev]

Hi,

Our IDE(wrapping lldb using python) works fine on Linux for simple hello
world cases. While trying a real world case, I found whenever we set a
source line breakpoint, then trigger the code path, lldb will send a
stopped state process event, with thread.GetStopReason() being None and
with weird callstack. Any ideas why do I get this stop stack(code is listed
at the end)? I have verified that if I do not set breakpoint and trigger
the same code path does not cause this stop event to generate.

bt
* thread #1: tid = 952490, 0x7fd7cb2daa83 libc.so.6`__GI_epoll_wait +
51, name = 'biggrep_master_'
  * frame #0: 0x7fd7cb2daa83 libc.so.6`__GI_epoll_wait + 51
frame #1: 0x0271189f
biggrep_master_server_async`epoll_dispatch(base=0x7fd7ca970800,
arg=0x7fd7ca62c1e0, tv=) + 127 at epoll.c:315
frame #2: 0x0270f6d1
biggrep_master_server_async`event_base_loop(base=0x7fd7ca970800,
flags=) + 225 at event.c:524
frame #3: 0x025f9378
biggrep_master_server_async`folly::EventBase::loopBody(this=0x7fd7ca945180,
flags=0) + 834 at EventBase.cpp:335
frame #4: 0x025f900b
biggrep_master_server_async`folly::EventBase::loop(this=0x7fd7ca945180)
+ 29 at EventBase.cpp:287
frame #5: 0x025fa053
biggrep_master_server_async`folly::EventBase::loopForever(this=0x7fd7ca945180)
+ 109 at EventBase.cpp:435
frame #6: 0x01e24b72
biggrep_master_server_async`apache::thrift::ThriftServer::serve(this=0x7fd7ca96d710)
+ 110 at ThriftServer.cpp:365
frame #7: 0x004906bc
biggrep_master_server_async`facebook::services::ServiceFramework::startFramework(this=0x7ffc06776140,
waitUntilStop=true) + 1942 at ServiceFramework.cpp:885
frame #8: 0x0048fe6d
biggrep_master_server_async`facebook::services::ServiceFramework::go(this=0x7ffc06776140,
waitUntilStop=true) + 35 at ServiceFramework.cpp:775
frame #9: 0x004219a7 biggrep_master_server_async`main(argc=1,
argv=0x7ffc067769d8) + 2306 at BigGrepMasterServerAsync.cpp:134
frame #10: 0x7fd7cb1ed0f6 libc.so.6`__libc_start_main + 246
frame #11: 0x00420bfc biggrep_master_server_async`_start + 41
at start.S:122

Here is the code snippet of handling code:
def _handle_process_event(self, event):
# Ignore non-stopping events.
if lldb.SBProcess.GetRestartedFromEvent(event):
log_debug('Non stopping event: %s' % str(event))
return

process = lldb.SBProcess.GetProcessFromEvent(event)
if process.state == lldb.eStateStopped:
self._send_paused_notification(process)
elif process.state == lldb.eStateExited:
exit_message = 'Process(%d) exited with: %u' % (
process.GetProcessID(),
process.GetExitStatus())
if process.GetExitDescription():
exit_message += (', ' + process.GetExitDescription())
self._send_user_output('log', exit_message)
self.should_quit = True
else:
self._send_notification('Debugger.resumed', None)

event_type = event.GetType()
if event_type == lldb.SBProcess.eBroadcastBitSTDOUT:
# Read stdout from inferior.
process_output = ''
while True:
output_part = process.GetSTDOUT(1024)
if not output_part or len(output_part) == 0:
break
process_output += output_part
self._send_user_output('log', process_output)
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Weird stop stack while hitting breakpoint

[Jeffrey Tan via lldb-dev]

Btw: the breakpoint I set is:
"b BigGrepMasterAsync.cpp:171" which is not in any of the stopped stack
frames.

On Fri, Mar 18, 2016 at 3:47 PM, Jeffrey Tan 
wrote:

> Hi,
>
> Our IDE(wrapping lldb using python) works fine on Linux for simple hello
> world cases. While trying a real world case, I found whenever we set a
> source line breakpoint, then trigger the code path, lldb will send a
> stopped state process event, with thread.GetStopReason() being None and
> with weird callstack. Any ideas why do I get this stop stack(code is listed
> at the end)? I have verified that if I do not set breakpoint and trigger
> the same code path does not cause this stop event to generate.
>
> bt
> * thread #1: tid = 952490, 0x7fd7cb2daa83 libc.so.6`__GI_epoll_wait +
> 51, name = 'biggrep_master_'
>   * frame #0: 0x7fd7cb2daa83 libc.so.6`__GI_epoll_wait + 51
> frame #1: 0x0271189f
> biggrep_master_server_async`epoll_dispatch(base=0x7fd7ca970800,
> arg=0x7fd7ca62c1e0, tv=) + 127 at epoll.c:315
> frame #2: 0x0270f6d1
> biggrep_master_server_async`event_base_loop(base=0x7fd7ca970800,
> flags=) + 225 at event.c:524
> frame #3: 0x025f9378
> biggrep_master_server_async`folly::EventBase::loopBody(this=0x7fd7ca945180,
> flags=0) + 834 at EventBase.cpp:335
> frame #4: 0x025f900b
> biggrep_master_server_async`folly::EventBase::loop(this=0x7fd7ca945180)
> + 29 at EventBase.cpp:287
> frame #5: 0x025fa053
> biggrep_master_server_async`folly::EventBase::loopForever(this=0x7fd7ca945180)
> + 109 at EventBase.cpp:435
> frame #6: 0x01e24b72
> biggrep_master_server_async`apache::thrift::ThriftServer::serve(this=0x7fd7ca96d710)
> + 110 at ThriftServer.cpp:365
> frame #7: 0x004906bc
> biggrep_master_server_async`facebook::services::ServiceFramework::startFramework(this=0x7ffc06776140,
> waitUntilStop=true) + 1942 at ServiceFramework.cpp:885
> frame #8: 0x0048fe6d
> biggrep_master_server_async`facebook::services::ServiceFramework::go(this=0x7ffc06776140,
> waitUntilStop=true) + 35 at ServiceFramework.cpp:775
> frame #9: 0x004219a7 biggrep_master_server_async`main(argc=1,
> argv=0x7ffc067769d8) + 2306 at BigGrepMasterServerAsync.cpp:134
> frame #10: 0x7fd7cb1ed0f6 libc.so.6`__libc_start_main + 246
> frame #11: 0x00420bfc biggrep_master_server_async`_start + 41
> at start.S:122
>
> Here is the code snippet of handling code:
> def _handle_process_event(self, event):
> # Ignore non-stopping events.
> if lldb.SBProcess.GetRestartedFromEvent(event):
> log_debug('Non stopping event: %s' % str(event))
> return
>
> process = lldb.SBProcess.GetProcessFromEvent(event)
> if process.state == lldb.eStateStopped:
> self._send_paused_notification(process)
> elif process.state == lldb.eStateExited:
> exit_message = 'Process(%d) exited with: %u' % (
> process.GetProcessID(),
> process.GetExitStatus())
> if process.GetExitDescription():
> exit_message += (', ' + process.GetExitDescription())
> self._send_user_output('log', exit_message)
> self.should_quit = True
> else:
> self._send_notification('Debugger.resumed', None)
>
> event_type = event.GetType()
> if event_type == lldb.SBProcess.eBroadcastBitSTDOUT:
> # Read stdout from inferior.
> process_output = ''
> while True:
> output_part = process.GetSTDOUT(1024)
> if not output_part or len(output_part) == 0:
> break
> process_output += output_part
> self._send_user_output('log', process_output)
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Weird stop stack while hitting breakpoint

[Jeffrey Tan via lldb-dev]

Thanks for the info. I understand the multiple threads stopping at the same
time issue. But I would think we should at least pick one stopped thread
and set it as selected thread instead of some random thread with stop
reason None. Also, in my repro case, there is only one thread that has stop
reason, so the heuristics should be pretty trivial to set selected thread
to that one.
I have workaround this issue with the suggestion but I think there is a
bug(on Linux) here.

On Fri, Mar 18, 2016 at 4:40 PM, Jim Ingham  wrote:

> On many platforms (OS X for sure) there’s no guarantee that when you stop
> you will only have hit one breakpoint on one thread.  On OS X in
> multithreaded programs, it is not at all uncommon to have many threads hit
> breakpoint(s) by the the time the stop gets reported.  So you just have to
> iterate over all the threads and see what their stop reasons are.  Note
> that it isn’t just breakpoints, you might have been stepping on thread A,
> and when you stop, thread A will have stopped with “plan complete” for the
> step operation, and thread B for some other breakpoint.
>
> So when you get a stop event you have to iterate over the threads and see
> why they have stopped.
>
> LLDB will set one of the threads as the selected thread, using some
> heuristics (if you were stepping on thread A & threads A & B stopped with
> breakpoints, thread A will be the selected thread, etc…)  So you could just
> show the selected thread, but really you want to figure out what all the
> threads are doing.
>
> Jim
>
> On Mar 18, 2016, at 4:25 PM, Jeffrey Tan  wrote:
>
>
> Hmm, interesting, I got the stop reason from
> the 
> lldb.SBProcess.GetProcessFromEvent(event).GetSelectedThread().GetStopReason().
> Is that thread not the one that stopped? But you are right, the breakpoint
> hits in another thread:
>
> thread #87: tid = 1006769, 0x0042eacd
> biggrep_master_server_async`facebook::biggrep::BigGrepMasterAsync::future_find(this=0x7f3ea2d74fd0,
> corpus=error: summary string parsing error, needle=error: summary string
> parsing error, options=0x7f3e899fc7e0) + 51 at
> *BigGrepMasterAsync.cpp:171*, name = 'BigGrep-pri3-32', *stop reason =
> breakpoint* 1.1
>
> How do I know which thread hits the breakpoint?
>
> Jeffrey
>
>
> On Fri, Mar 18, 2016 at 4:12 PM, Jim Ingham  wrote:
>
>> You only show one thread in your example.  Did another thread have a
>> valid stop reason?  lldb shouldn’t be stopping for no reason anywhere…
>>
>> Jim
>>
>> On Mar 18, 2016, at 4:08 PM, Jeffrey Tan via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> Btw: the breakpoint I set is:
>> "b BigGrepMasterAsync.cpp:171" which is not in any of the stopped stack
>> frames.
>>
>> On Fri, Mar 18, 2016 at 3:47 PM, Jeffrey Tan 
>> wrote:
>>
>>> Hi,
>>>
>>> Our IDE(wrapping lldb using python) works fine on Linux for simple hello
>>> world cases. While trying a real world case, I found whenever we set a
>>> source line breakpoint, then trigger the code path, lldb will send a
>>> stopped state process event, with thread.GetStopReason() being None and
>>> with weird callstack. Any ideas why do I get this stop stack(code is listed
>>> at the end)? I have verified that if I do not set breakpoint and trigger
>>> the same code path does not cause this stop event to generate.
>>>
>>> bt
>>> * thread #1: tid = 952490, 0x7fd7cb2daa83 libc.so.6`__GI_epoll_wait
>>> + 51, name = 'biggrep_master_'
>>>   * frame #0: 0x7fd7cb2daa83 libc.so.6`__GI_epoll_wait + 51
>>> frame #1: 0x0271189f
>>> biggrep_master_server_async`epoll_dispatch(base=0x7fd7ca970800,
>>> arg=0x7fd7ca62c1e0, tv=) + 127 at epoll.c:315
>>> frame #2: 0x0270f6d1
>>> biggrep_master_server_async`event_base_loop(base=0x7fd7ca970800,
>>> flags=) + 225 at event.c:524
>>> frame #3: 0x025f9378
>>> biggrep_master_server_async`folly::EventBase::loopBody(this=0x7fd7ca945180,
>>> flags=0) + 834 at EventBase.cpp:335
>>> frame #4: 0x025f900b
>>> biggrep_master_server_async`folly::EventBase::loop(this=0x7fd7ca945180)
>>> + 29 at EventBase.cpp:287
>>> frame #5: 0x025fa053
>>> biggrep_master_server_async`folly::EventBase::loopForever(this=0x7fd7ca945180)
>>> + 109 at EventBase.cpp:435
>>> frame #6: 0x01e24b72
>>> biggrep_master_server_async`apache::thrift::ThriftServer::serve(this=0x7fd7ca96d710)
>>> + 110 at ThriftServer.cpp:365

Re: [lldb-dev] Weird stop stack while hitting breakpoint

[Jeffrey Tan via lldb-dev]

Hmm, interesting, I got the stop reason from
the 
lldb.SBProcess.GetProcessFromEvent(event).GetSelectedThread().GetStopReason().
Is that thread not the one that stopped? But you are right, the breakpoint
hits in another thread:

thread #87: tid = 1006769, 0x0042eacd
biggrep_master_server_async`facebook::biggrep::BigGrepMasterAsync::future_find(this=0x7f3ea2d74fd0,
corpus=error: summary string parsing error, needle=error: summary string
parsing error, options=0x7f3e899fc7e0) + 51 at
*BigGrepMasterAsync.cpp:171*, name = 'BigGrep-pri3-32', *stop reason =
breakpoint* 1.1

How do I know which thread hits the breakpoint?

Jeffrey


On Fri, Mar 18, 2016 at 4:12 PM, Jim Ingham  wrote:

> You only show one thread in your example.  Did another thread have a valid
> stop reason?  lldb shouldn’t be stopping for no reason anywhere…
>
> Jim
>
> On Mar 18, 2016, at 4:08 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Btw: the breakpoint I set is:
> "b BigGrepMasterAsync.cpp:171" which is not in any of the stopped stack
> frames.
>
> On Fri, Mar 18, 2016 at 3:47 PM, Jeffrey Tan 
> wrote:
>
>> Hi,
>>
>> Our IDE(wrapping lldb using python) works fine on Linux for simple hello
>> world cases. While trying a real world case, I found whenever we set a
>> source line breakpoint, then trigger the code path, lldb will send a
>> stopped state process event, with thread.GetStopReason() being None and
>> with weird callstack. Any ideas why do I get this stop stack(code is listed
>> at the end)? I have verified that if I do not set breakpoint and trigger
>> the same code path does not cause this stop event to generate.
>>
>> bt
>> * thread #1: tid = 952490, 0x7fd7cb2daa83 libc.so.6`__GI_epoll_wait +
>> 51, name = 'biggrep_master_'
>>   * frame #0: 0x7fd7cb2daa83 libc.so.6`__GI_epoll_wait + 51
>> frame #1: 0x0271189f
>> biggrep_master_server_async`epoll_dispatch(base=0x7fd7ca970800,
>> arg=0x7fd7ca62c1e0, tv=) + 127 at epoll.c:315
>> frame #2: 0x0270f6d1
>> biggrep_master_server_async`event_base_loop(base=0x7fd7ca970800,
>> flags=) + 225 at event.c:524
>> frame #3: 0x025f9378
>> biggrep_master_server_async`folly::EventBase::loopBody(this=0x7fd7ca945180,
>> flags=0) + 834 at EventBase.cpp:335
>> frame #4: 0x025f900b
>> biggrep_master_server_async`folly::EventBase::loop(this=0x7fd7ca945180)
>> + 29 at EventBase.cpp:287
>> frame #5: 0x025fa053
>> biggrep_master_server_async`folly::EventBase::loopForever(this=0x7fd7ca945180)
>> + 109 at EventBase.cpp:435
>> frame #6: 0x01e24b72
>> biggrep_master_server_async`apache::thrift::ThriftServer::serve(this=0x7fd7ca96d710)
>> + 110 at ThriftServer.cpp:365
>> frame #7: 0x004906bc
>> biggrep_master_server_async`facebook::services::ServiceFramework::startFramework(this=0x7ffc06776140,
>> waitUntilStop=true) + 1942 at ServiceFramework.cpp:885
>> frame #8: 0x0048fe6d
>> biggrep_master_server_async`facebook::services::ServiceFramework::go(this=0x7ffc06776140,
>> waitUntilStop=true) + 35 at ServiceFramework.cpp:775
>> frame #9: 0x004219a7 biggrep_master_server_async`main(argc=1,
>> argv=0x7ffc067769d8) + 2306 at BigGrepMasterServerAsync.cpp:134
>> frame #10: 0x7fd7cb1ed0f6 libc.so.6`__libc_start_main + 246
>> frame #11: 0x00420bfc biggrep_master_server_async`_start + 41
>> at start.S:122
>>
>> Here is the code snippet of handling code:
>> def _handle_process_event(self, event):
>> # Ignore non-stopping events.
>> if lldb.SBProcess.GetRestartedFromEvent(event):
>> log_debug('Non stopping event: %s' % str(event))
>> return
>>
>> process = lldb.SBProcess.GetProcessFromEvent(event)
>> if process.state == lldb.eStateStopped:
>> self._send_paused_notification(process)
>> elif process.state == lldb.eStateExited:
>> exit_message = 'Process(%d) exited with: %u' % (
>> process.GetProcessID(),
>> process.GetExitStatus())
>> if process.GetExitDescription():
>> exit_message += (', ' + process.GetExitDescription())
>> self._send_user_output('log', exit_message)
>> self.should_quit = True
>> else:
>> self._send_notification('Debugger.resumed', None)
>>
>> event_type = event.Ge

Re: [lldb-dev] [Bug 26978] New: LLDB stack overflow while dealing with symbols for a process on Linux

[Jeffrey Tan via lldb-dev]

Seems like the crashes happens because of abi::__cxa_demangle() for mangled
symbol name "
_ZNSt9_Any_data9_M_accessIPPZN5folly6fibers12FiberManager16runInMainContextIZN8facebook8memcache15CacheClientImplINS6_17CControllerCommonINS1_7dynamic11multiOpSyncINS6_11McOperationILi11EEESt6vect
".

This is blocking us from releasing our C++ debugging support. Anyone know
of a quick workaround I can fix it locally? Thanks!

On Thu, Mar 17, 2016 at 12:25 PM, via lldb-dev 
wrote:

> Bug ID 26978 
> Summary LLDB stack overflow while dealing with symbols for a process on
> Linux
> Product lldb
> Version 3.8
> Hardware PC
> OS Linux
> Status NEW
> Severity release blocker
> Priority P
> Component All Bugs
> Assignee lldb-dev@lists.llvm.org
> Reporter jeffrey.fu...@gmail.com
> CC llvm-b...@lists.llvm.org
> Classification Unclassified
>
> While using lldb to attach a process in our company on Linux, lldb segment
> fault with a huge stack(more than 30K stack frames). I assume it crashes
> because of stack overflow. Let me know what additional information you 
> needed(I
> have coredump):
>
> #0  0x7f28ce530819 in d_print_comp (dpi=0x7f28c2728c00, options=17,
> dc=0x7f28c2724b80) at cp-demangle.c:4286
> #1  0x7f28ce5321e6 in d_print_comp (dpi=0x7f28c2728c00, options=17,
> dc=0x7f28c2724bb0) at cp-demangle.c:4324
> #2  0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c2724c10) at cp-demangle.c:4324
> #3  0x7f28ce532010 in d_print_comp (dpi=0x7f28c2728c00, options=17,
> dc=0x7f28c2724c70) at cp-demangle.c:4489
> #4  0x7f28ce5319c0 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c2724c88) at cp-demangle.c:4923
> #5  0x7f28ce532056 in d_print_comp (dpi=0x7f28c2728c00, options=17,
> dc=0x7f28c2724ca0) at cp-demangle.c:4493
> #6  0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c2724cd0) at cp-demangle.c:4324
> #7  0x7f28ce532010 in d_print_comp (dpi=0x7f28c2728c00, options=17,
> dc=0x7f28c2725030) at cp-demangle.c:4489
> #8  0x7f28ce535353 in d_print_mod (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, mod=) at cp-demangle.c:5539
> #9  0x7f28ce535dbe in d_print_mod_list (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, mods=mods@entry=0x7f28c1f2ba30,
> suffix=suffix@entry=0) at cp-demangle.c:5468
> #10 0x7f28ce5366a1 in d_print_function_type (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, mods=0x7f28c1f2ba30, dc=0x7f28c2725138) at
> cp-demangle.c:5609
> #11 0x7f28ce53110c in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c2725138) at cp-demangle.c:4808
> #12 0x7f28ce530a01 in d_print_comp (dpi=0x7f28c2728c00, options=17,
> dc=0x7f28c2725150) at cp-demangle.c:4434
> #13 0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c27251b0) at cp-demangle.c:4324
> #14 0x7f28ce5336b3 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c2725108) at cp-demangle.c:4529
> #15 0x7f28ce534448 in d_print_comp (dpi=0x7f28c2728c00, options= out>, dc=0x7f28c2725270) at cp-demangle.c:4793
> #16 0x7f28ce5319c0 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c2725288) at cp-demangle.c:4923
> #17 0x7f28ce532056 in d_print_comp (dpi=0x7f28c2728c00, options=17,
> dc=0x7f28c27252a0) at cp-demangle.c:4493
> #18 0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c27252d0) at cp-demangle.c:4324
> #19 0x7f28ce534448 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c2725318) at cp-demangle.c:4793
> #20 0x7f28ce530a01 in d_print_comp (dpi=0x7f28c2728c00, options=17,
> dc=0x7f28c2725330) at cp-demangle.c:4434
> #21 0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c2725390) at cp-demangle.c:4324
> #22 0x7f28ce53123b in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c27253a8) at cp-demangle.c:4742
> #23 0x7f28ce53123b in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c27253c0) at cp-demangle.c:4742
> #24 0x7f28ce5336b3 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c2725108) at cp-demangle.c:4529
> #25 0x7f28ce53123b in d_print_comp (dpi=0x7f28c2728c00, options=17,
> dc=0x7f28c27252e8) at cp-demangle.c:4742
> #26 0x7f28ce5319c0 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c2725300) at cp-demangle.c:4923
> #27 0x7f28ce5366e1 in d_print_function_type (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, mods=0x7f28c1f2cc70, dc=0x7f28c2725318) at
> cp-demangle.c:5617
> #28 0x7f28ce53110c in d_print_comp (dpi=dpi@entry=0x7f

Re: [lldb-dev] [Bug 26978] New: LLDB stack overflow while dealing with symbols for a process on Linux

[Jeffrey Tan via lldb-dev]

Thanks Jim. This is very helpful.
We have double checked the libiberty we are building against which seems
already be updated two weeks ago so this bug might not been fixed yet.
Rebuilding LLDB_USE_BUILTIN_DEMANGLER fixed this stack overflow.

Questions:
1. Any reason LLDB_USE_BUILTIN_DEMANGLER is not used for other platforms?
2. Any side-effect if I use LLDB_USE_BUILTIN_DEMANGLER for lldb on other
platform?

On Thu, Mar 17, 2016 at 7:04 PM, Jim Ingham  wrote:

> The code that has gotten itself into an infinite loop here is the
> libiberty cp-demangle.c, which is part of the C++ runtime libraries for the
> system you are on.  So we can't do anything to fix bugs with that.  You
> might make sure there isn't a newer version of that than the one on your
> system, but other than fixing the bugs in it yourself, there's not much we
> can do about that one.
>
> However, if you build lldb with LLDB_USE_BUILTIN_DEMANGLER defined it will
> do two things, it will trigger the FastDemangler that Kate wrote, and if
> that succeeds, yay!  Otherwise it will fall back to another demangler that
> comes along with the C++ standard libraries from the llvm project.  That
> one, like the cp-demangle.c is very stack intensive, but it might not have
> whatever bug you are triggering in the libiberty one.  And if it does have
> crashing bugs somebody in the clang world could fix them...
>
> Anyway, you might try that and see if you have any more luck.  IIRC,
> FreeBSD uses the llvm one in favor of the libiberty one.
>
> Jim
>
>
> > On Mar 17, 2016, at 6:09 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > This is crazy. I tried 10MB, not working, then 20MB still not working. I
> got around 80K frames stack overflow, this is clearly an infinitely loop in
> "d_print_comp":
> >
> > (gdb) bt
> > #0  0x7f35925511e1 in d_print_comp (dpi=0x7f3586747c00, options=17,
> dc=0x7f3586743bb0) at cp-demangle.c:4324
> > #1  0x7f35925511e6 in d_print_comp (dpi=dpi@entry=0x7f3586747c00,
> options=options@entry=17, dc=0x7f3586743be0) at cp-demangle.c:4324
> > #2  0x7f3592551010 in d_print_comp (dpi=0x7f3586747c00, options=17,
> dc=0x7f3586743ca0) at cp-demangle.c:4489
> > #3  0x7f35925511e6 in d_print_comp (dpi=dpi@entry=0x7f3586747c00,
> options=options@entry=17, dc=0x7f3586743cd0) at cp-demangle.c:4324
> > #4  0x7f3592551010 in d_print_comp (dpi=0x7f3586747c00, options=17,
> dc=0x7f3586744030) at cp-demangle.c:4489
> > #5  0x7f3592554353 in d_print_mod (dpi=dpi@entry=0x7f3586747c00,
> options=options@entry=17, mod=) at cp-demangle.c:5539
> > #6  0x7f3592554dbe in d_print_mod_list (dpi=dpi@entry=0x7f3586747c00,
> options=options@entry=17, mods=mods@entry=0x7f358534a7b0,
> suffix=suffix@entry=0) at cp-demangle.c:5468
> > #7  0x7f35925556a1 in d_print_function_type 
> > (dpi=dpi@entry=0x7f3586747c00,
> options=options@entry=17, mods=0x7f358534a7b0, dc=0x7f3586744138) at
> cp-demangle.c:5609
> > #8  0x7f359255010c in d_print_comp (dpi=dpi@entry=0x7f3586747c00,
> options=options@entry=17, dc=0x7f3586744138) at cp-demangle.c:4808
> > #9  0x7f359254fa01 in d_print_comp (dpi=0x7f3586747c00, options=17,
> dc=0x7f3586744150) at cp-demangle.c:4434
> > .
> >
> > #79590 0x7f35925526b3 in d_print_comp (dpi=dpi@entry=0x7f3586747c00,
> options=options@entry=17, dc=0x7f3586744108) at cp-demangle.c:4529
> > #79591 0x7f359255023b in d_print_comp (dpi=dpi@entry=0x7f3586747c00,
> options=options@entry=17, dc=0x7f3586744408) at cp-demangle.c:4742
> > #79592 0x7f3592553448 in d_print_comp (dpi=dpi@entry=0x7f3586747c00,
> options=options@entry=17, dc=0x7f3586744450) at cp-demangle.c:4793
> > #79593 0x7f359254fa01 in d_print_comp (dpi=dpi@entry=0x7f3586747c00,
> options=options@entry=17, dc=dc@entry=0x7f3586744468) at
> cp-demangle.c:4434
> > #79594 0x7f3592555f53 in d_demangle_callback (options=17,
> opaque=0x7f3586742cc0, callback=0x7f359254b820
> , dc=0x7f3586744468) at
> cp-demangle.c:4063
> > #79595 0x7f3592555f53 in d_demangle_callback (mangled= out>,
> > mangled@entry=0x0, callback=callback@entry=0x7f359254b820
> , opaque=opaque@entry=0x7f3586747db0,
> options=17) at cp-demangle.c:5865
> > #79596 0x7f359255609f in __cxa_demangle (options=17, palc= pointer>, mangled=0x0) at cp-demangle.c:5886
> >
> > #79597 0x7f359255609f in __cxa_demangle
> (mangled_name=mangled_name@entry=0x7f3570e3d460
> "_ZNSt9_Any_data9_M_accessIPPZN5folly6fibers12FiberManager16runInMainContextIZN8facebook8memcache15CacheClientImplINS6_17CControllerCommonINS1_7dynamic11multiOpSyncINS6_11McOperationILi11EEESt6vect"...,
> output_buf

Re: [lldb-dev] [Bug 26978] New: LLDB stack overflow while dealing with symbols for a process on Linux

[Jeffrey Tan via lldb-dev]

JITLoaderGDB::SetJITBreakpoint(lldb_private::ModuleList&)
(this=0x7f3570042990, module_list=...)
at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp:177
#79605 0x7f359432b910 in
lldb_private::JITLoaderList::ModulesDidLoad(lldb_private::ModuleList&)
(this=, module_list=...)
at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Target/JITLoaderList.cpp:76
#79606 0x7f35942c80f8 in
lldb_private::Process::ModulesDidLoad(lldb_private::ModuleList&)
(this=this@entry=0x8919b0, module_list=...)
at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Target/Process.cpp:6370
#79607 0x7f3594412091 in
lldb_private::process_gdb_remote::ProcessGDBRemote::ModulesDidLoad(lldb_private::ModuleList&)
(this=0x8919b0, module_list=...)
at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:4927
#79608 0x7f35942f2131 in
lldb_private::Target::ModulesDidLoad(lldb_private::ModuleList&)
(this=0x88d0d0, module_list=...)
at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Target/Target.cpp:1400
#79609 0x7f35942fbb58 in
lldb_private::Target::ModuleAdded(lldb_private::ModuleList const&,
std::shared_ptr const&) (this=0x88d0d0,
module_list=..., module_sp=...)
at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Target/Target.cpp:1364
#79610 0x7f3594187f28 in
lldb_private::ModuleList::AppendImpl(std::shared_ptr
const&, bool) (this=0x88d3d0, module_sp=..., use_notifier=use_notifier@entry
=true)
at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Core/ModuleList.cpp:110
#79611 0x7f3594187f6a in
lldb_private::ModuleList::Append(std::shared_ptr
const&) (this=, module_sp=...)
at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Core/ModuleList.cpp:117
#79612 0x7f35942f0def in
lldb_private::Target::GetSharedModule(lldb_private::ModuleSpec const&,
lldb_private::Error*) (this=this@entry=0x88d0d0, module_spec=...,
error_ptr=error_ptr@entry=0x0)
at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Target/Target.cpp:1924
#79613 0x7f359463fb48 in
lldb_private::DynamicLoader::LoadModuleAtAddress(lldb_private::FileSpec
const&, unsigned long, unsigned long, bool) (this=,
file=..., link_map_addr=139710961516544, base_addr=139710941827072,
base_addr_is_offset=) at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Core/DynamicLoader.cpp:192
#79614 0x7f35943a664a in
DynamicLoaderPOSIXDYLD::LoadAllCurrentModules() (this=0x7f3570038570)
---Type  to continue, or q  to quit---
at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp:521
#79615 0x7f35943a88f0 in DynamicLoaderPOSIXDYLD::DidAttach()
(this=0x7f3570038570)
at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp:181
#79616 0x7f35942c546c in lldb_private::Process::CompleteAttach()
(this=0x8919b0) at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Target/Process.cpp:3443
#79617 0x7f35942c6236 in
lldb_private::Process::AttachCompletionHandler::PerformAction(std::shared_ptr&)
(this=0x8b5f60, event_sp=...)
at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Target/Process.cpp:3194
#79618 0x7f35942ce98c in
lldb_private::Process::HandlePrivateEvent(std::shared_ptr&)
(this=this@entry=0x8919b0, event_sp=...)
at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Target/Process.cpp:4184
#79619 0x7f35942cf9bd in
lldb_private::Process::RunPrivateStateThread(bool) (this=0x8919b0,
is_secondary_thread=)
at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Target/Process.cpp:4429
#79620 0x7f3594127421 in
lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(void*)
(arg=0x8b5f40)
at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Host/common/HostNativeThreadBase.cpp:81
#79621 0x7f3592a43aa1 in start_thread () at /lib64/libpthread.so.0
#79622 0x7f3591da593d in clone () at /lib64/libc.so.6

On Thu, Mar 17, 2016 at 2:41 PM, Kate Stone 
wrote:

> The cxa_demangle implementation definitely consumes stack aggressively,
> especially when compiled -O0.  I’d definitely recommend an 8MB+ stack for
> any thread that may wind up demangling arbitrary C++ symbols.  The new
> “fast demangler” is much more conservative with stack space but doesn’t yet
> support the full name mangling specification, so complex symbols often rely
> on falling back to cxa_demangle.
>
> Kate Stone k8st...@apple.com
>  Xcode Low Level Tools
>
> On Mar 17, 2016, at 2:19 PM, Greg Clayton via lldb-dev <
&

Re: [lldb-dev] Weird stop stack while hitting breakpoint

[Jeffrey Tan via lldb-dev]

._handle_thread_event(event)
else:
self._handle_unknown_event(event)
print ' Exiting listener thread'

def _handle_target_event(self, event):
event_type = event.GetType()
print 'Target event: %s' % target_event_type_to_name_map[event_type]

def _handle_process_event(self, event):
if lldb.SBProcess.GetRestartedFromEvent(event):
print 'Non stopping event: %s' % str(event)
return
process = lldb.SBProcess.GetProcessFromEvent(event)
event_type = event.GetType()
print 'Process event: %s, %s' %
(process_event_type_to_name_map[event_type],
process_state_name_map[process.state])
if process.state == lldb.eStateExited:
self.should_quit = True
elif process.state == lldb.eStateStopped:
if self._stopped_sigal:
self._stopped_sigal.set()
else:
if self._running_signal:
self._running_signal.set()

thread = process.selected_thread
print 'Stop reason: %d' % thread.GetStopReason()
if event_type == lldb.SBProcess.eBroadcastBitSTDOUT:
print 'Stdout:'
while True:
output = process.GetSTDOUT(1024)
if output is None or len(output) == 0:
break
stdout.write(output)

def _handle_breakpoint_event(self, event):
breakpoint = lldb.SBBreakpoint.GetBreakpointFromEvent(event)
event_type =
lldb.SBBreakpoint.GetBreakpointEventTypeFromEvent(event)
print 'Breakpoint event: [%s] %s ' % (
breakpoint_event_type_to_name_map[event_type],
self._get_description_from_object(breakpoint))

def _handle_unknown_event(self, event):
print('Unknown event: %d %s %s' % (
event.GetType(),
lldb.SBEvent.GetCStringFromEvent(event),
self._get_description_from_object(event)))

def _get_description_from_object(self, lldb_object):
description_stream = lldb.SBStream()
lldb_object.GetDescription(description_stream)
return description_stream.GetData()





On Sun, Mar 20, 2016 at 7:10 AM, Pavel Labath  wrote:

> If you send me a small repro case, I can try to look at why is Linux
> different here.
>
> On 19 March 2016 at 00:46, Jim Ingham via lldb-dev
>  wrote:
> > All this logic is handled in Process::HandleProcessStateChangedEvent
> (see around line 1215 in Process.cpp)  You shouldn’t have to reimplement
> the logic for setting the selected thread unless you don’t like our
> heuristics.  Note, that’s in generic code, so I don’t know why it wouldn’t
> be working right on Linux.
> >
> > Jim
> >
> >> On Mar 18, 2016, at 5:38 PM, Greg Clayton  wrote:
> >>
> >> It is really up to the IDE to decide this so the logic belongs in your
> IDE. We do things as follows:
> >>
> >> If no thread was selected before, display the first thread that has a
> stop reason other than none. If no threads have stop reasons, select the
> first thread. If a thread was selected before, then see if that same thread
> is stopped with a reason the next time you stop and select that one,
> regardless if it is the first thread with a stop reason. The idea is, if
> you were stepping or doing something in a thread, and then stop again, you
> don't want the IDE changing away from your current thread if this thread
> has a stop reason. If this thread doesn't have a stop reason, then select
> the first one that does. If not threads have stop reasons, then display the
> same thread as before.
> >>
> >>> On Mar 18, 2016, at 5:23 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>>
> >>> Thanks for the info. I understand the multiple threads stopping at the
> same time issue. But I would think we should at least pick one stopped
> thread and set it as selected thread instead of some random thread with
> stop reason None. Also, in my repro case, there is only one thread that has
> stop reason, so the heuristics should be pretty trivial to set selected
> thread to that one.
> >>> I have workaround this issue with the suggestion but I think there is
> a bug(on Linux) here.
> >>>
> >>> On Fri, Mar 18, 2016 at 4:40 PM, Jim Ingham  wrote:
> >>> On many platforms (OS X for sure) there’s no guarantee that when you
> stop you will only have hit one breakpoint on one thread.  On OS X in
> multithreaded programs, it is not at all uncommon to have many threads hit
> breakpoint(s) by the the time the stop gets reported.  So you just have to
> iterate over all the threads and see what their stop reasons are.  Note
> that it is

[lldb-dev] UnicodeDecodeError for serialize SBValue description

[Jeffrey Tan via lldb-dev]

Follow-up for the previous question:

Our python code is trying to call json.dumps to serialize the variable
evaluation result into string block and send to IDE via RPC, however it
failed with "UnicodeDecodeError: 'utf8' codec can't decode byte 0xc9 in
position 10: invalid continuation byte" because SBValue.description seems
to return non-utf-8 string:

(lldb) fr v
*error: biggrep_master_server_async 0x10b9a91a: DW_TAG_member '_M_pod_data'
refers to type 0x10bb1e99 which extends beyond the bounds of 0x10b9a901*
*error: biggrep_master_server_async 0x10b98edc: DW_TAG_member 'small_'
refers to type 0x10bb1d9f which extends beyond the bounds of 0x10b98ed3*
*error: biggrep_master_server_async 0x10baf034: DW_TAG_member '__size'
refers to type 0x10baf04d which extends beyond the bounds of 0x10baefae*
(facebook::biggrep::BigGrepMasterAsync *) this = 0x7fd14d374fd0
(const string &const) corpus = error: summary string parsing error: {
  store_ = {
 = {
  small_ = {}
  *ml_ = (data_ =
"��UH\x89�H�}�H\x8bE�]ÐUH\x89�H��H\x89}�H\x8bE�H\x89��~\xb4��\x90��UH\x89�SH\x83�H\x89}�H�u�H�E�H���\x9e���H\x8b\x18H\x8bE�H���O\xb4��H\x89ƿ\b",
size_ = 0, capacity_ = 1441151880758558720)*
}
  }
}


File
"/data/users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide-debugger-lldb-server/scripts/chromedebugger.py",
line 91, in received_message
*response_in_json = json.dumps(response);*
  File "/usr/lib64/python2.6/json/__init__.py", line 230, in dumps
return _default_encoder.encode(obj)
  File "/usr/lib64/python2.6/json/encoder.py", line 367, in encode
chunks = list(self.iterencode(o))
  File "/usr/lib64/python2.6/json/encoder.py", line 309, in _iterencode
for chunk in self._iterencode_dict(o, markers):
  File "/usr/lib64/python2.6/json/encoder.py", line 275, in _iterencode_dict
for chunk in self._iterencode(value, markers):
  File "/usr/lib64/python2.6/json/encoder.py", line 309, in _iterencode
for chunk in self._iterencode_dict(o, markers):
  File "/usr/lib64/python2.6/json/encoder.py", line 275, in _iterencode_dict
for chunk in self._iterencode(value, markers):
  File "/usr/lib64/python2.6/json/encoder.py", line 306, in _iterencode
for chunk in self._iterencode_list(o, markers):
  File "/usr/lib64/python2.6/json/encoder.py", line 204, in _iterencode_list
for chunk in self._iterencode(value, markers):
  File "/usr/lib64/python2.6/json/encoder.py", line 309, in _iterencode
for chunk in self._iterencode_dict(o, markers):
  File "/usr/lib64/python2.6/json/encoder.py", line 275, in _iterencode_dict
for chunk in self._iterencode(value, markers):
  File "/usr/lib64/python2.6/json/encoder.py", line 309, in _iterencode
for chunk in self._iterencode_dict(o, markers):
  File "/usr/lib64/python2.6/json/encoder.py", line 275, in _iterencode_dict
for chunk in self._iterencode(value, markers):
  File "/usr/lib64/python2.6/json/encoder.py", line 294, in _iterencode
yield encoder(o)
*UnicodeDecodeError: 'utf8' codec can't decode byte 0xc9 in position 10:
invalid continuation byte*

Question:
Is the non utf-8 string expected or just gabage data because of the
DW_TAG_member
error? What is the proper way find out the string encoding and serialize
using* json.dumps()*?

Jeffrey
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Fwd: DW_TAG_member extends beyond the bounds error on Linux

[Jeffrey Tan via lldb-dev]

Sorry, sent to the wrong alias.

-- Forwarded message --
From: Jeffrey Tan 
Date: Sat, Mar 26, 2016 at 3:19 PM
Subject: DW_TAG_member extends beyond the bounds error on Linux
To: llvm-...@lists.llvm.org


Hi,

While dogfooding our lldb based IDE on Linux, I am seeing a lot of variable
evaluation errors related to DW_TAG_member which prevents us from release
the IDE. Can anyone help to confirm if they are known issues? If not, any
information you need to troubleshoot this issue?

Here is one example:

(lldb) fr v
*error: biggrep_master_server_async 0x10b9a91a: DW_TAG_member '_M_pod_data'
refers to type 0x10bb1e99 which extends beyond the bounds of 0x10b9a901*
*error: biggrep_master_server_async 0x10b98edc: DW_TAG_member 'small_'
refers to type 0x10bb1d9f which extends beyond the bounds of 0x10b98ed3*
*error: biggrep_master_server_async 0x10baf034: DW_TAG_member '__size'
refers to type 0x10baf04d which extends beyond the bounds of 0x10baefae*
(facebook::biggrep::BigGrepMasterAsync *) this = 0x7fd14d374fd0
(const string &const) corpus = error: summary string parsing error: {
  store_ = {
 = {
  small_ = {}
  *ml_ = (data_ =
"��UH\x89�H�}�H\x8bE�]ÐUH\x89�H��H\x89}�H\x8bE�H\x89��~\xb4��\x90��UH\x89�SH\x83�H\x89}�H�u�H�E�H���\x9e���H\x8b\x18H\x8bE�H���O\xb4��H\x89ƿ\b",
size_ = 0, capacity_ = 1441151880758558720)*
}
  }
}
*(const string &const) needle = error: summary string parsing error: {*
  store_ = {
 = {
  small_ = {}
  ml_ = (data_ = "", size_ = 0, capacity_ = 1080863910568919040)
}
  }
}
(facebook::biggrep::Options &) options = 0x7fd133cfb7b0: {
  engine = error: summary string parsing error
  full_lines = true
  user = error: summary string parsing error
  max_bytes = 500
  leading_context = 0
  trailing_context = 0
  case_sensitive = true
  client_hostname = error: summary string parsing error
  client_ip = error: summary string parsing error
  skip_logging = false
  client_port = 0
  shards_override = 0
  sample = false
  count = false
  filename_pattern = error: summary string parsing error
  limit = 0
  __isset = {
engine = true
full_lines = true
user = true
max_bytes = true
leading_context = true
trailing_context = true
case_sensitive = true
client_hostname = true
client_ip = true
skip_logging = true
client_port = true
shards_override = true
sample = true
count = true
filename_pattern = true
limit = true
  }
}
(size_t) recv_timeout = 140536468041728
(std::vector,
std::allocator, std::fbstring_core >,
std::allocator,
std::allocator, std::fbstring_core > > >) corpuses = size=0 {}
(std::vector >)
revisions = size=0 {}
(std::vector >)
shards = size=0 {}
*(std::string) returnRev = error: summary string parsing error*
() quote = {}
(std::basic_fbstring, std::allocator,
std::fbstring_core >) desc = {
  store_ = {
 = {
  small_ = {}
  ml_ = (data_ = "", size_ = 73415312, capacity_ = 140536494141696)
}
  }
}
(folly::EventBase *) eb = 0x7fd133cfb888
(apache::thrift::concurrency::ThreadManager *) tm = 0x7fd133cfb570

I suspect each one may be different root cause. I was able to capture one
callstack of a small repro:

Breakpoint 1, DWARFASTParserClang::ParseChildMembers (this=0x8c4520,
sc=..., parent_die=..., class_clang_type=...,
class_language=lldb::eLanguageTypeUnknown,
base_classes=..., member_accessibilities=..., member_function_dies=...,
delayed_properties=...,
default_accessibility=@0x7ffdf3888cac: lldb::eAccessPublic,
is_a_class=@0x7ffdf3888cab: false, layout_info=...)
at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2937
2937
 parent_die.GetID());
(gdb) bt
#0  0x7f103d02533d in
DWARFASTParserClang::ParseChildMembers(lldb_private::SymbolContext const&,
DWARFDIE const&, lldb_private::CompilerType&, lldb::LanguageType,
std::vector >&, std::vector >&, DWARFDIECollection&,
std::vector >&,
lldb::AccessType&, bool&, DWARFASTParserClang::LayoutInfo&) (this=0x8c4520,
sc=..., parent_die=..., class_clang_type=...,
class_language=lldb::eLanguageTypeUnknown, base_classes=...,
member_accessibilities=..., member_function_dies=...,
delayed_properties=..., default_accessibility=@0x7ffdf3888cac:
lldb::eAccessPublic, is_a_class=@0x7ffdf3888cab: false, layout_info=...) at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2937
#1  0x7f103d025b84 in
DWARFASTParserClang::CompleteTypeFromDWARF(DWARFDIE const&,
lldb_private::Type*, lldb_private::CompilerType&) (this=0x8c4520, die=...,
type=0xc40a50, clang_type=...)
at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2036
#2  0x7f103d04c5e8 in
SymbolFileDWARF::CompleteType(lldb_private::CompilerType&) (this=, compiler_type=...)
at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb

Re: [lldb-dev] [llvm-dev] DW_TAG_member extends beyond the bounds error on Linux

[Jeffrey Tan via lldb-dev]

Thanks David. I meant to send to lldb maillist, but glad to hear response
here.

Our binary is built from gcc:
String dump of section '.comment':
  [ 1]  GCC: (GNU) 4.9.x-google 20150123 (prerelease)

Is there any similar flags we should use? By doing "strings -a [binary] |
grep -i gcc", I found the following flags being used:
GNU C++ 4.9.x-google 20150123 (prerelease) -momit-leaf-frame-pointer -m64
-mtune=generic -march=x86-64 -g -O3 -O3 -std=gnu++11 -ffunction-sections
-fdata-sections -fstack-protector -fno-omit-frame-pointer
-fdebug-prefix-map=/home/engshare/third-party2/icu/53.1/src/icu=/home/engshare/third-party2/icu/53.1/src/icu
-fdebug-prefix-map=/home/engshare/third-party2/icu/53.1/src/build-gcc-4.9-glibc-2.20-fb/no-pic=/home/engshare/third-party2/icu/53.1/src/icu
-fno-strict-aliasing --param ssp-buffer-size=4

Also, per reading
https://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Debugging-Options.html, seems
that we should use "-gdwarf-2" to generate only standard DWARF format? I
think I might need to chat with our build team but want to know which flag
I need ask them first.

Btw: I tried gdb against the same binary which seems to get better result:

(gdb) p corpus
$3 = (const std::string &) @0x7fd133cfb888: {
  static npos = 18446744073709551615, store_ = {
static kIsLittleEndian = ,
static kIsBigEndian = , {
  small_ = "www", '\000' , "\024", ml_ = {
data_ = 0x77 ::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1},
void>::type::value_type
folly::fibers::await::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1}>(folly::fibers::FirstArgOf&&)::{lambda()#1}>(folly::fibers::FiberManager&,
folly::fibers::FirstArgOf::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1},
void>::type::value_type
folly::fibers::await::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1}>(folly::fibers::FirstArgOf&&)::{lambda()#1},
void>::type::value_type)::{lambda(folly::fibers::Fiber&)#1}*>() const+25>
"\311\303UH\211\345H\211}\370H\213E\370]ÐUH\211\345H\203\354\020H\211}\370H\213E\370H\211\307\350~\264\312\377\220\311\303UH\211\345SH\203\354\030H\211}\350H\211u\340H\213E\340H\211\307\350\236\377\377\377H\213\030H\213E\350H\211\307\350O\264\312\377H\211ƿ\b",
size_ = 0,
capacity_ = 1441151880758558720

Jeffrey



On Sat, Mar 26, 2016 at 8:22 PM, David Blaikie  wrote:

> If you're going to use clang built binaries with lldb, you'll want to pass
> -fstandalone-debug - this is the default on platforms where lldb is the
> primary debugger (Darwin and freebsd)
>
> Not sure if that is the problem you are seeing, but will be a problem
> sooner or later
> On Mar 26, 2016 4:16 PM, "Jeffrey Tan via llvm-dev" <
> llvm-...@lists.llvm.org> wrote:
>
>> Hi,
>>
>> While dogfooding our lldb based IDE on Linux, I am seeing a lot of
>> variable evaluation errors related to DW_TAG_member which prevents us from
>> release the IDE. Can anyone help to confirm if they are known issues? If
>> not, any information you need to troubleshoot this issue?
>>
>> Here is one example:
>>
>> (lldb) fr v
>> *error: biggrep_master_server_async 0x10b9a91a: DW_TAG_member
>> '_M_pod_data' refers to type 0x10bb1e99 which extends beyond the bounds of
>> 0x10b9a901*
>> *error: biggrep_master_server_async 0x10b98edc: DW_TAG_member 'small_'
>> refers to type 0x10bb1d9f which extends beyond the bounds of 0x10b98ed3*
>> *error: biggrep_master_server_async 0x10baf034: DW_TAG_member '__size'
>> refers to type 0x10baf04d which extends beyond the bounds of 0x10baefae*
>> (facebook::biggrep::BigGrepMasterAsync *) this = 0x7fd14d374fd0
>> (const string &const) corpus = error: summary string parsing error: {
>>   store_ = {
>>  = {
>>   small_ = {}
>>   *ml_ = (data_ =
>> "��UH\x89�H�}�H\x8bE�]ÐUH\x89�H��H\x89}�H\x8bE�H\x89��~\xb4��\x90��UH\x89�SH\x83�H\x89}�H�u�H�E�H���\x9e���H\x8b\x18H\x8bE�H���O\xb4��H\x89ƿ\b",
>> size_ = 0, capacity_ = 1441151880758558720)*
>> }
>>   }
>> }
>> *(const string &const) needle = error: summary string parsing error: {*
>>   store_ = {
>>  = {
>>   small_ = {}
>>   ml_ = (data_ = "", size_ = 0, capacity_ = 1080863910568919040)
>> }
>>   }
>> }
>> (facebook::biggrep::Options &) options = 0x7fd133cfb7b0: {
>>   engine = error: summary string parsing error
>>   full_lines = true
>>   user = error: summary string parsing error
>>   max_bytes = 500
>>   leading_context = 0
>>   trailing_context = 0
>>   case_sensitive = true
>>   client_hostname = error: summary st

Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description

[Jeffrey Tan via lldb-dev]

Btw: after patching with Siva's fix http://reviews.llvm.org/D18008, the
first field 'small_' is fixed, however the second field 'ml_' still emits
garbage:

(lldb) fr v corpus
(const string &const) corpus = error: summary string parsing error: {
  store_ = {
 = {
  small_ = "www"
  ml_ = (data_ =
"��UH\x89�H�}�H\x8bE�]ÐUH\x89�H��H\x89}�H\x8bE�H\x89��~\xb4��\x90��UH\x89�SH\x83�H\x89}�H�u�H�E�H���\x9e���H\x8b\x18H\x8bE�H���O\xb4��H\x89ƿ\b",
size_ = 0, capacity_ = 1441151880758558720)
}
  }
}

Thanks for any info regarding how to encode this string.

Jeffrey

On Sat, Mar 26, 2016 at 3:34 PM, Jeffrey Tan 
wrote:

> Follow-up for the previous question:
>
> Our python code is trying to call json.dumps to serialize the variable
> evaluation result into string block and send to IDE via RPC, however it
> failed with "UnicodeDecodeError: 'utf8' codec can't decode byte 0xc9 in
> position 10: invalid continuation byte" because SBValue.description seems
> to return non-utf-8 string:
>
> (lldb) fr v
> *error: biggrep_master_server_async 0x10b9a91a: DW_TAG_member
> '_M_pod_data' refers to type 0x10bb1e99 which extends beyond the bounds of
> 0x10b9a901*
> *error: biggrep_master_server_async 0x10b98edc: DW_TAG_member 'small_'
> refers to type 0x10bb1d9f which extends beyond the bounds of 0x10b98ed3*
> *error: biggrep_master_server_async 0x10baf034: DW_TAG_member '__size'
> refers to type 0x10baf04d which extends beyond the bounds of 0x10baefae*
> (facebook::biggrep::BigGrepMasterAsync *) this = 0x7fd14d374fd0
> (const string &const) corpus = error: summary string parsing error: {
>   store_ = {
>  = {
>   small_ = {}
>   *ml_ = (data_ =
> "��UH\x89�H�}�H\x8bE�]ÐUH\x89�H��H\x89}�H\x8bE�H\x89��~\xb4��\x90��UH\x89�SH\x83�H\x89}�H�u�H�E�H���\x9e���H\x8b\x18H\x8bE�H���O\xb4��H\x89ƿ\b",
> size_ = 0, capacity_ = 1441151880758558720)*
> }
>   }
> }
>
>
> File
> "/data/users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide-debugger-lldb-server/scripts/chromedebugger.py",
> line 91, in received_message
> *response_in_json = json.dumps(response);*
>   File "/usr/lib64/python2.6/json/__init__.py", line 230, in dumps
> return _default_encoder.encode(obj)
>   File "/usr/lib64/python2.6/json/encoder.py", line 367, in encode
> chunks = list(self.iterencode(o))
>   File "/usr/lib64/python2.6/json/encoder.py", line 309, in _iterencode
> for chunk in self._iterencode_dict(o, markers):
>   File "/usr/lib64/python2.6/json/encoder.py", line 275, in
> _iterencode_dict
> for chunk in self._iterencode(value, markers):
>   File "/usr/lib64/python2.6/json/encoder.py", line 309, in _iterencode
> for chunk in self._iterencode_dict(o, markers):
>   File "/usr/lib64/python2.6/json/encoder.py", line 275, in
> _iterencode_dict
> for chunk in self._iterencode(value, markers):
>   File "/usr/lib64/python2.6/json/encoder.py", line 306, in _iterencode
> for chunk in self._iterencode_list(o, markers):
>   File "/usr/lib64/python2.6/json/encoder.py", line 204, in
> _iterencode_list
> for chunk in self._iterencode(value, markers):
>   File "/usr/lib64/python2.6/json/encoder.py", line 309, in _iterencode
> for chunk in self._iterencode_dict(o, markers):
>   File "/usr/lib64/python2.6/json/encoder.py", line 275, in
> _iterencode_dict
> for chunk in self._iterencode(value, markers):
>   File "/usr/lib64/python2.6/json/encoder.py", line 309, in _iterencode
> for chunk in self._iterencode_dict(o, markers):
>   File "/usr/lib64/python2.6/json/encoder.py", line 275, in
> _iterencode_dict
> for chunk in self._iterencode(value, markers):
>   File "/usr/lib64/python2.6/json/encoder.py", line 294, in _iterencode
> yield encoder(o)
> *UnicodeDecodeError: 'utf8' codec can't decode byte 0xc9 in position 10:
> invalid continuation byte*
>
> Question:
> Is the non utf-8 string expected or just gabage data because of the 
> DW_TAG_member
> error? What is the proper way find out the string encoding and serialize
> using* json.dumps()*?
>
> Jeffrey
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description

[Jeffrey Tan via lldb-dev]

Thanks Siva. All the *DW_TAG_member *related errors seems to go away after
patching with your fix. The current problem is handling the decoding.

Here is the correct decoding from gdb whic might be useful:
(gdb) p corpus
$3 = (const std::string &) @0x7fd133cfb888: {
  static npos = 18446744073709551615, store_ = {
static kIsLittleEndian = ,
static kIsBigEndian = , {
  small_ = "www", '\000' , "\024", ml_ = {
data_ = 0x77 ::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1},
void>::type::value_type
folly::fibers::await::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1}>(folly::fibers::FirstArgOf&&)::{lambda()#1}>(folly::fibers::FiberManager&,
folly::fibers::FirstArgOf::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1},
void>::type::value_type
folly::fibers::await::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1}>(folly::fibers::FirstArgOf&&)::{lambda()#1},
void>::type::value_type)::{lambda(folly::fibers::Fiber&)#1}*>() const+25>
"\311\303UH\211\345H\211}\370H\213E\370]ÐUH\211\345H\203\354\020H\211}\370H\213E\370H\211\307\350~\264\312\377\220\311\303UH\211\345SH\203\354\030H\211}\350H\211u\340H\213E\340H\211\307\350\236\377\377\377H\213\030H\213E\350H\211\307\350O\264\312\377H\211ƿ\b",
size_ = 0,
capacity_ = 1441151880758558720

Utf-16 does not seem to decode it, while 'latin-1' does:
>>> '\xc9'.decode('utf-16')
Traceback (most recent call last):
  File "", line 1, in 
  File
"/mnt/gvfs/third-party2/python/55c1fd79d91c77c95932db31a4769919611c12bb/2.7.8/centos6-native/da39a3e/lib/python2.7/encodings/utf_16.py",
line 16, in decode
return codecs.utf_16_decode(input, errors, True)
UnicodeDecodeError: 'utf16' codec can't decode byte 0xc9 in position 0:
truncated data
>>> '\xc9'.decode('latin-1')
u'\xc9'

Instead of guessing what kind of decoding I should use, I would use
'ensure_ascii=False' to prevent the crash for now.

I tried to reproduce this crash, but it seems that the crash might be
related with some internal stl implementation we are using. I will see if I
can narrow down to a small repro later.

Thanks
Jeffrey

On Sun, Mar 27, 2016 at 2:49 PM, Siva Chandra  wrote:

> On Sat, Mar 26, 2016 at 11:58 PM, Jeffrey Tan 
> wrote:
> > Btw: after patching with Siva's fix http://reviews.llvm.org/D18008, the
> > first field 'small_' is fixed, however the second field 'ml_' still emits
> > garbage:
> >
> > (lldb) fr v corpus
> > (const string &const) corpus = error: summary string parsing error: {
> >   store_ = {
> >  = {
> >   small_ = "www"
> >   ml_ = (data_ =
> >
> "��UH\x89�H�}�H\x8bE�]ÐUH\x89�H��H\x89}�H\x8bE�H\x89��~\xb4��\x90��UH\x89�SH\x83�H\x89}�H�u�H�E�H���\x9e���H\x8b\x18H\x8bE�H���O\xb4��H\x89ƿ\b",
> > size_ = 0, capacity_ = 1441151880758558720)
> > }
> >   }
> > }
>
> Do you still see the DW_TAG_member related error?
>
> A wild (and really wild at that) guess: Is it utf16 data that is being
> decoded as utf8?
>
> As David Blaikie mentioned on the other thread, it would really help
> if you provide us with a minimal example to repro this. Atleast, repro
> instructions.
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] DW_TAG_member extends beyond the bounds error on Linux

[Jeffrey Tan via lldb-dev]

 you will be
> able to see the DWARF that is causing the problem. On MacOSX, I would do
> this:
> >
> > % dwarfdump --debug-info=0x10b9a91a --show-children --show-parents
> biggrep_master_server_async
> >
> > llvm-dwarfdump will dump your entire file and you will need to look
> through a ton of DWARF in the output. You will need to search for
> "0x10b9a91a:" (the offset followed by a colon).
> >
> > So LLDB believes it is pointing out an error in the DWARF that needs to
> be fixed in the compiler. It could be an incorrect error, but I would need
> to see the DWARF in question to know more. Debugging can happen just fine
> if you ignore this error, it is actually more of a warning, but we emit an
> error so users know to file a bug and hopefully get the compiler fixed.
> >
> > Greg
> >
> >> On Mar 26, 2016, at 5:10 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>
> >> Sorry, sent to the wrong alias.
> >>
> >> -- Forwarded message --
> >> From: Jeffrey Tan 
> >> Date: Sat, Mar 26, 2016 at 3:19 PM
> >> Subject: DW_TAG_member extends beyond the bounds error on Linux
> >> To: llvm-...@lists.llvm.org
> >>
> >>
> >> Hi,
> >>
> >> While dogfooding our lldb based IDE on Linux, I am seeing a lot of
> variable evaluation errors related to DW_TAG_member which prevents us from
> release the IDE. Can anyone help to confirm if they are known issues? If
> not, any information you need to troubleshoot this issue?
> >>
> >> Here is one example:
> >>
> >> (lldb) fr v
> >> error: biggrep_master_server_async 0x10b9a91a: DW_TAG_member
> '_M_pod_data' refers to type 0x10bb1e99 which extends beyond the bounds of
> 0x10b9a901
> >> error: biggrep_master_server_async 0x10b98edc: DW_TAG_member 'small_'
> refers to type 0x10bb1d9f which extends beyond the bounds of 0x10b98ed3
> >> error: biggrep_master_server_async 0x10baf034: DW_TAG_member '__size'
> refers to type 0x10baf04d which extends beyond the bounds of 0x10baefae
> >> (facebook::biggrep::BigGrepMasterAsync *) this = 0x7fd14d374fd0
> >> (const string &const) corpus = error: summary string parsing error: {
> >>  store_ = {
> >> = {
> >>  small_ = {}
> >>  ml_ = (data_ =
> "��UH\x89�H�}�H\x8bE�]ÐUH\x89�H��H\x89}�H\x8bE�H\x89��~\xb4��\x90��UH\x89�SH\x83�H\x89}�H�u�H�E�H���\x9e���H\x8b\x18H\x8bE�H���O\xb4��H\x89ƿ\b",
> size_ = 0, capacity_ = 1441151880758558720)
> >>}
> >>  }
> >> }
> >> (const string &const) needle = error: summary string parsing error: {
> >>  store_ = {
> >> = {
> >>  small_ = {}
> >>  ml_ = (data_ = "", size_ = 0, capacity_ = 1080863910568919040)
> >>}
> >>  }
> >> }
> >> (facebook::biggrep::Options &) options = 0x7fd133cfb7b0: {
> >>  engine = error: summary string parsing error
> >>  full_lines = true
> >>  user = error: summary string parsing error
> >>  max_bytes = 500
> >>  leading_context = 0
> >>  trailing_context = 0
> >>  case_sensitive = true
> >>  client_hostname = error: summary string parsing error
> >>  client_ip = error: summary string parsing error
> >>  skip_logging = false
> >>  client_port = 0
> >>  shards_override = 0
> >>  sample = false
> >>  count = false
> >>  filename_pattern = error: summary string parsing error
> >>  limit = 0
> >>  __isset = {
> >>engine = true
> >>full_lines = true
> >>user = true
> >>max_bytes = true
> >>leading_context = true
> >>trailing_context = true
> >>case_sensitive = true
> >>client_hostname = true
> >>client_ip = true
> >>skip_logging = true
> >>client_port = true
> >>shards_override = true
> >>sample = true
> >>count = true
> >>filename_pattern = true
> >>limit = true
> >>  }
> >> }
> >> (size_t) recv_timeout = 140536468041728
> >> (std::vector,
> std::allocator, std::fbstring_core >,
> std::allocator,
> std::allocator, std::fbstring_core > > >) corpuses = size=0 {}
> >> (std::vector std::allocator >)
> revisions = size=0 {}
> >> (std::vector std::allocator >)
> shards = size=0 {}
> >> (std::string) returnRev = error: summary string parsing 

Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description

[Jeffrey Tan via lldb-dev]

n'
>   __lx = '\n'
> }
> __data_ = {
>   [0] = 'h'
>   [1] = 'e'
>   [2] = 'l'
>   [3] = 'l'
>   [4] = 'o'
>   [5] = '\0'
>   [6] = '\0'
>   [7] = '\0'
>   [8] = '\0'
>   [9] = '\0'
>   [10] = '\0'
>   [11] = '\0'
>   [12] = '\0'
>   [13] = '\0'
>   [14] = '\0'
>   [15] = '\0'
>           [16] = '\0'
>   [17] = '\0'
>   [18] = '\0'
>   [19] = '\0'
>   [20] = '\0'
>   [21] = '\0'
>   [22] = '\0'
> }
>   }
>   __r = {
> __words = {
>   [0] = 122511465736202
>   [1] = 0
>   [2] = 0
> }
>   }
> }
>   }
> }
>   }
> }
>
> So the main question is why are our "std::string" formatters not kicking
> in for you. That comes down to a typename match, or the format of the
> string isn't what the formatter is expecting.
>
> But again, since you std::string can contain anything, you will need to
> escape any and all text that is encoded into JSON to ensure it doesn't
> contain anything JSON can't deal with.
>
> > On Mar 27, 2016, at 9:20 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Thanks Siva. All the DW_TAG_member related errors seems to go away after
> patching with your fix. The current problem is handling the decoding.
> >
> > Here is the correct decoding from gdb whic might be useful:
> > (gdb) p corpus
> > $3 = (const std::string &) @0x7fd133cfb888: {
> >   static npos = 18446744073709551615, store_ = {
> > static kIsLittleEndian = ,
> > static kIsBigEndian = , {
> >   small_ = "www", '\000' , "\024", ml_ = {
> > data_ = 0x77  folly::fibers::Baton::waitFiber::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1},
> void>::type::value_type
> folly::fibers::await::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1}>(folly::fibers::FirstArgOf&&)::{lambda()#1}>(folly::fibers::FiberManager&,
> folly::fibers::FirstArgOf::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1},
> void>::type::value_type
> folly::fibers::await::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1}>(folly::fibers::FirstArgOf&&)::{lambda()#1},
> void>::type::value_type)::{lambda(folly::fibers::Fiber&)#1}*>() const+25>
> "\311\303UH\211\345H\211}\370H\213E\370]ÐUH\211\345H\203\354\020H\211}\370H\213E\370H\211\307\350~\264\312\377\220\311\303UH\211\345SH\203\354\030H\211}\350H\211u\340H\213E\340H\211\307\350\236\377\377\377H\213\030H\213E\350H\211\307\350O\264\312\377H\211ƿ\b",
> size_ = 0,
> > capacity_ = 1441151880758558720
> >
> > Utf-16 does not seem to decode it, while 'latin-1' does:
> > >>> '\xc9'.decode('utf-16')
> > Traceback (most recent call last):
> >   File "", line 1, in 
> >   File
> "/mnt/gvfs/third-party2/python/55c1fd79d91c77c95932db31a4769919611c12bb/2.7.8/centos6-native/da39a3e/lib/python2.7/encodings/utf_16.py",
> line 16, in decode
> > return codecs.utf_16_decode(input, errors, True)
> > UnicodeDecodeError: 'utf16' codec can't decode byte 0xc9 in position 0:
> truncated data
> > >>> '\xc9'.decode('latin-1')
> > u'\xc9'
> >
> > Instead of guessing what kind of decoding I should use, I would use
> 'ensure_ascii=False' to prevent the crash for now.
> >
> > I tried to reproduce this crash, but it seems that the crash might be
> related with some internal stl implementation we are using. I will see if I
> can narrow down to a small repro later.
> >
> > Thanks
> > Jeffrey
> >
> > On Sun, Mar 27, 2016 at 2:49 PM, Siva Chandra 
> wrote:
> > On Sat, Mar 26, 2016 at 11:58 PM, Jeffrey Tan 
> wrote:
> > > Btw: after patching with Siva's fix http://reviews.llvm.org/D18008,
> the
> > > first field 'small_' is fixed, however the second field 'ml_' still
> emits
> > > garbage:
> > >
> > > (lldb) fr v corpus
> > > (const string &const) corpus = error: summary string parsing error: {
> > >   store_ = {
> > >  = {
> > >   small_ = "www"
> > >   ml_ = (data_ =
> > >
> "��UH\x89�H�}�H\x8bE�]ÐUH\x89�H��H\x89}�H\x8bE�H\x89��~\xb4��\x90��UH\x89�SH\x83�H\x89}�H�u�H�E�H���\x9e���H\x8b\x18H\x8bE�H���O\xb4��H\x89ƿ\b",
> > > size_ = 0, capacity_ = 1441151880758558720)
> > > }
> > >   }
> > > }
> >
> > Do you still see the DW_TAG_member related error?
> >
> > A wild (and really wild at that) guess: Is it utf16 data that is being
> > decoded as utf8?
> >
> > As David Blaikie mentioned on the other thread, it would really help
> > if you provide us with a minimal example to repro this. Atleast, repro
> > instructions.
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description

[Jeffrey Tan via lldb-dev]

Thanks, I will try this escape mechanism for the returned C string.

On Mon, Mar 28, 2016 at 1:04 PM, Greg Clayton  wrote:

>
> > On Mar 28, 2016, at 11:38 AM, Jeffrey Tan 
> wrote:
> >
> > Thanks Greg for the detailed explanation, very helpful.
> > 1. Just to confirm, the weird string displayed is because 'data_' points
> to some random memory?
>
> Yes.
>
> > So what gdb displays is also some random memory content not something
> that more meaningful than us? I thought we(lldb) did not display
> std::string content well but gdb does it correct.
>
> So the "size_" variable is zero, so anything that GDB is displaying is
> shear luck of what the contents of memory are that "data_" points to. You
> can't rely on any contents of "data_" since it is clearly bogus. What you
> really want to see is just the string that "std::string" points to:
>
> (std::string) my_string = "Hello"
>
> Or for a std::string that contains 0, 1, and 2 as characters:
>
> (std::string) my_string = "\x00\x01\x02"
>
>
>
> > 2. I guess the std::string formatter did not kick in because our company
> may link some special stl implementation. Let me share our binary for you
> to confirm.
>
> You can get some help from Enrico to see why things are not displaying
> correctly. My guess is this C++ standard library is different from the ones
> that we added support for.
>
> > 3. I dumped the content of the object we try to json.dumps() against,
> here is the content:
> > response: {'id':  57, 'result': {'result': [{'name': 'data_',
> 'value': {'type': 'object', 'description': '(char *)
> "\xc9\xc3UH\\x89\xe5H\x8
>  
> 9}\xf8H\\x8bE\xf8]\xc3\x90UH\\x89\xe5H\x83\xec\x10H\\x89}\xf8H\\x8bE\xf8H\\x89\xc7\xe8~\\xb4\xca\xff\\x90\xc9\xc3UH\\x89\
>
>  
> xe5SH\\x83\xec\x18H\\x89}\xe8H\x89u\xe0H\x8bE\xe0H\x89\xc7\xe8\\x9e\xff\xff\xffH\\x8b\\x18H\\x8bE\xe8H\x89\xc7\xe8O\\xb4\
>xca\xffH\\x89\xc6\xbf\\b"', 'objectId': 'RemoteObjectManager.118'}},
> {'name': 'size_', 'value': {'type': 'object', 'descr iption':
> '(std::size_t) 0'}}, {'name': 'capacity_', 'value': {'type': 'object',
> 'description': '(std::size_t) 14411518807 58558720'}}]}}
> > So seems that the problem is json.dumps() is trying to treat the raw
> byte array as utf8 which failed.
> > So we need to figure out how to escape the raw byte array into string so
> that we can json.dumps() it. The key question is how do we know the correct
> encoding of the byte array.
>
> It doesn't really matter. Just know that any of the strings from:
>
> const char *SBValue::GetName();
> const char *SBValue::GetTypeName ();
> const char *SBValue::GetDisplayTypeName();
> const char *SBValue::GetValue();
> const char *SBValue::GetSummary();
> const char *SBValue::GetObjectDescription();
> const char *SBValue::GetLocation ();
>
> Will need to be escaped.
>
> > Is my understanding correct that only the formatter has the knowledge to
> decode the byte array correctly?
>
> We dump the values as strings. You won't get bytes out. You might get UTF8
> bytes or other things that JSON might interpret as special characters and
> any C strings that you get from the above calls will just need to be
> escaped if needed.
>
> > If we fail to find a type formatter(which is this case) and get a raw
> field with byte array, we have no knowledge of the encoding so either we
> have to guess one default encoding and try it or just display the raw byte
> array content instead of decoding it?
>
> Again, this is all C strings. I don't think anything else matters.
>
> Our JSON.cpp has the following:
>
> int
> JSONParser::GetEscapedChar(bool &was_escaped)
> {
> was_escaped = false;
> const char ch = GetChar();
> if (ch == '\\')
> {
> was_escaped = true;
> const char ch2 = GetChar();
> switch (ch2)
> {
> case '"':
> case '\\':
> case '/':
> default:
> break;
>
> case 'b': return '\b';
> case 'f': return '\f';
> case 'n': return '\n';
> case 'r': return '\r';
> case 't': return '\t';
> case 'u':
> {
> const int hi_byte = DecodeHexU8();
> const int lo_byte = DecodeHexU8();
> if (hi_byte >=0 && lo_byte >= 0)
> return hi_byte << 8 | lo_byte;
> return -1;
> }
> break;
> }
> return ch2;
> }
> return ch;
> }
>
> You can see how it is used when the JSON parser is parsing in
> JSONParser::GetToken() in the '"' case.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] How to detach from stop mode without causing signal in inferior on Linux?

[Jeffrey Tan via lldb-dev]

Hi,

When user tries to stop debugging, we call SBDebugger.Destroy(), then
SBDebugger.Terminate() and exit the python process. This works well on mac,
but on linux in running mode. However, I found if the debugger hits
breakpoint first, then user stops debugging, the inferior is killed with
siginal:
"*Trace/breakpoint trap*"

I tried to call SBTarget.DeleteAllBreakpoints() first before killing
debugger. Still the same result.

Jeffrey
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] How to detach from stop mode without causing signal in inferior on Linux?

[Jeffrey Tan via lldb-dev]

Thanks Pavel. I think I know what's going on. We do call SBProcess.Detach()
during exiting python process normally. However, our stop debugging code
seems to only kill python process directly without letting it exit
normally.
Killing python process seems to detach from inferior on Mac but kills
inferior on Linux. But I guess that's because of the implementation
difference, for example, Linux might left an embeded breakpoint in the
inferior process without clean-up which caused the inferior to signal
with "*Trace/breakpoint
trap*".
I will try to send a detach command to python before killing it.

Jeffrey

On Tue, Mar 29, 2016 at 2:08 AM, Pavel Labath  wrote:

> Hi,
>
> are you doing a SBProcess.Detach() before you kill the debugger? If
> that doesn't help could you send me the gdb-remote packet form
> (execute command: log enable -f /some/file.log gdb-remote packets), so
> I can get a better idea of what is going on.
>
> cheers,
> pl
>
>
> On 29 March 2016 at 00:21, Jeffrey Tan via lldb-dev
>  wrote:
> > Hi,
> >
> > When user tries to stop debugging, we call SBDebugger.Destroy(), then
> > SBDebugger.Terminate() and exit the python process. This works well on
> mac,
> > but on linux in running mode. However, I found if the debugger hits
> > breakpoint first, then user stops debugging, the inferior is killed with
> > siginal:
> > "Trace/breakpoint trap"
> >
> > I tried to call SBTarget.DeleteAllBreakpoints() first before killing
> > debugger. Still the same result.
> >
> > Jeffrey
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description

[Jeffrey Tan via lldb-dev]

3] = 'l'
>  [4] = 'o'
>  [5] = '\0'
>  [6] = '\0'
>  [7] = '\0'
>  [8] = '\0'
>  [9] = '\0'
>  [10] = '\0'
>  [11] = '\0'
>  [12] = '\0'
>  [13] = '\0'
>  [14] = '\0'
>  [15] = '\0'
>  [16] = '\0'
>  [17] = '\0'
>  [18] = '\0'
>  [19] = '\0'
>          [20] = '\0'
>  [21] = '\0'
>  [22] = '\0'
>}
>  }
>  __r = {
>__words = {
>  [0] = 122511465736202
>  [1] = 0
>  [2] = 0
>}
>  }
>}
>  }
>}
>  }
> }
>
> So the main question is why are our "std::string" formatters not kicking
> in for you. That comes down to a typename match, or the format of the
> string isn't what the formatter is expecting.
>
> But again, since you std::string can contain anything, you will need to
> escape any and all text that is encoded into JSON to ensure it doesn't
> contain anything JSON can't deal with.
>
> On Mar 27, 2016, at 9:20 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Thanks Siva. All the DW_TAG_member related errors seems to go away after
> patching with your fix. The current problem is handling the decoding.
>
> Here is the correct decoding from gdb whic might be useful:
> (gdb) p corpus
> $3 = (const std::string &) @0x7fd133cfb888: {
>  static npos = 18446744073709551615, store_ = {
>static kIsLittleEndian = ,
>static kIsBigEndian = , {
>  small_ = "www", '\000' , "\024", ml_ = {
>data_ = 0x77  folly::fibers::Baton::waitFiber::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1},
> void>::type::value_type
> folly::fibers::await::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1}>(folly::fibers::FirstArgOf&&)::{lambda()#1}>(folly::fibers::FiberManager&,
> folly::fibers::FirstArgOf::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1},
> void>::type::value_type
> folly::fibers::await::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1}>(folly::fibers::FirstArgOf&&)::{lambda()#1},
> void>::type::value_type)::{lambda(folly::fibers::Fiber&)#1}*>() const+25>
> "\311\303UH\211\345H\211}\370H\213E\370]ÐUH\211\345H\203\354\020H\211}\370H\213E\370H\211\307\350~\264\312\377\220\311\303UH\211\345SH\203\354\030H\211}\350H\211u\340H\213E\340H\211\307\350\236\377\377\377H\213\030H\213E\350H\211\307\350O\264\312\377H\211ƿ\b",
> size_ = 0,
>capacity_ = 1441151880758558720
>
> Utf-16 does not seem to decode it, while 'latin-1' does:
>
> '\xc9'.decode('utf-16')
>
> Traceback (most recent call last):
>  File "", line 1, in 
>  File
> "/mnt/gvfs/third-party2/python/55c1fd79d91c77c95932db31a4769919611c12bb/2.7.8/centos6-native/da39a3e/lib/python2.7/encodings/utf_16.py",
> line 16, in decode
>return codecs.utf_16_decode(input, errors, True)
> UnicodeDecodeError: 'utf16' codec can't decode byte 0xc9 in position 0:
> truncated data
>
> '\xc9'.decode('latin-1')
>
> u'\xc9'
>
> Instead of guessing what kind of decoding I should use, I would use
> 'ensure_ascii=False' to prevent the crash for now.
>
> I tried to reproduce this crash, but it seems that the crash might be
> related with some internal stl implementation we are using. I will see if I
> can narrow down to a small repro later.
>
> Thanks
> Jeffrey
>
> On Sun, Mar 27, 2016 at 2:49 PM, Siva Chandra 
> wrote:
> On Sat, Mar 26, 2016 at 11:58 PM, Jeffrey Tan 
> wrote:
>
> Btw: after patching with Siva's fix http://reviews.llvm.org/D18008, the
> first field 'small_' is fixed, however the second field 'ml_' still emits
> garbage:
>
> (lldb) fr v corpus
> (const string &const) corpus = error: summary string parsing error: {
>  store_ = {
> = {
>  small_ = "www"
>  ml_ = (data_ =
>
> "��UH\x89�H�}�H\x8bE�]ÐUH\x89�H��H\x89}�H\x8bE�H\x89��~\xb4��\x90��UH\x89�SH\x83�H\x89}�H�u�H�E�H���\x9e���H\x8b\x18H\x8bE�H���O\xb4��H\x89ƿ\b",
> size_ = 0, capacity_ = 1441151880758558720)
>}
>  }
> }
>
>
> Do you still see the DW_TAG_member related error?
>
> A wild (and really wild at that) guess: Is it utf16 data that is being
> decoded as utf8?
>
> As David Blaikie mentioned on the other thread, it would really help
> if you provide us with a minimal example to repro this. Atleast, repro
> instructions.
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
> Thanks,
> *- Enrico*
> 📩 egranata@.com ☎️ 27683
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description

[Jeffrey Tan via lldb-dev]

ngCoreSummaryProvider()
>
>
> I understand this may seem a little convoluted and arcane at first - but
> feel free to ask more questions, and I’ll try to help out!
>
> Thanks.
> Jeffrey
>
> On Mon, Mar 28, 2016 at 11:38 AM, Enrico Granata 
> wrote:
>
>> This is kind of orthogonal to your problem, but the reason why you are
>> not seeing the kind of simplified printing Greg is suggesting, is because
>> your std::string doesn’t look like any of the kinds we recognize
>>
>> Specifically, LLDB data formatters work by matching against type names,
>> and once they recognize a typename, then they try to inspect the variable
>> in order to grab a summary
>> In your example, your std::string exposes a layout that we are not
>> handling - hence we bail out of the formatter and we fall back to the raw
>> view
>>
>> If you want pretty printing to work, you’ll need to write a data formatter
>>
>> There are a few avenues. The obvious easy one is to extend the existing
>> std::string formatter to recognize your type’s internal layout.
>> If one were signing up for more infrastructure work, they could decide to
>> try and detect shared library loads and load formatters that match with
>> whatever libraries are being loaded.
>>
>> On Mar 28, 2016, at 9:47 AM, Greg Clayton via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> So you need to be prepared to escape any text that can have special
>> characters. A "std::string" or any container can contain special
>> characters. If you are encoding stuff into JSON, you will either need to
>> escape any special characters, or hex encode the string into ASCII hex
>> bytes.
>>
>> In debuggers we often get bogus data because variables are not
>> initialized, but the compiler tells us that a variable is valid in address
>> range [0x1000-0x2000), but it actually is [0x1200-0x2000). If we read a
>> variable in this case, a std::string might contain bogus data and the bytes
>> might not make sense. So you always have to be prepared for bad data.
>>
>> If we look at:
>>
>>  store_ = {
>> = {
>>  small_ = "www"
>>  ml_ = (data_ =
>>
>> "��UH\x89�H�}�H\x8bE�]ÐUH\x89�H��H\x89}�H\x8bE�H\x89��~\xb4��\x90��UH\x89�SH\x83�H\x89}�H�u�H�E�H���\x9e���H\x8b\x18H\x8bE�H���O\xb4��H\x89ƿ\b",
>> size_ = 0, capacity_ = 1441151880758558720)
>>}
>>  }
>> }
>>
>> We can see the "size_" is zero, and capacity_ is 1441151880758558720
>> (which is 0x1400). "data_" seems to be some random pointer.
>>
>> On MacOSX, we have a special formatting code that displays std::string in
>> CPlusPlusLanguage.cpp that gets installed in the LoadLibCxxFormatters() or
>> LoadLibStdcppFormatters() functions with code like:
>>
>>lldb::TypeSummaryImplSP std_string_summary_sp(new
>> CXXFunctionSummaryFormat(stl_summary_flags,
>> lldb_private::formatters::LibcxxStringSummaryProvider, "std::string summary
>> provider"));
>>
>> cpp_category_sp->GetTypeSummariesContainer()->Add(ConstString("std::__1::string"),
>> std_string_summary_sp);
>>
>> Special flags are set on std::string to say "don't show children of this
>> and just show a summary" So if a std::string contained "hello". So for the
>> following code:
>>
>> std::string h ("hello");
>>
>> You should just see:
>>
>> (lldb) fr var h
>> (std::__1::string) h = "hello"
>>
>> If you take a look at the normal value in the raw we see:
>>
>> (lldb) fr var --raw h
>> (std::__1::string) h = {
>>  __r_ = {
>>std::__1::__libcpp_compressed_pair_imp> std::__1::char_traits, std::__1::allocator >::__rep,
>> std::__1::allocator, 2> = {
>>  __first_ = {
>> = {
>>  __l = {
>>__cap_ = 122511465736202
>>__size_ = 0
>>__data_ = 0x
>>  }
>>  __s = {
>> = {
>>  __size_ = '\n'
>>  __lx = '\n'
>>}
>>__data_ = {
>>  [0] = 'h'
>>  [1] = 'e'
>>  [2] = 'l'
>>  [3] = 'l'
>>  [4] = 'o'
>>  [5] = '\0'
>>  [6] = '\0'
>>  [7] = '\0'
>>  [8] = '\0'
>

Re: [lldb-dev] Weird stop stack while hitting breakpoint

[Jeffrey Tan via lldb-dev]

dded/Removed/Disabled/etc).
> > broadcaster = target.GetBroadcaster()
> > mask = lldb.SBTarget.eBroadcastBitBreakpointChanged |
> > lldb.SBTarget.eBroadcastBitWatchpointChanged |
> > lldb.SBTarget.eBroadcastBitModulesLoaded
> > broadcaster.AddListener(self.listener, mask)
> >
> > def _add_listener_to_process(self, process):
> > # Listen for process events (Start/Stop/Interrupt/etc).
> > broadcaster = process.GetBroadcaster()
> > mask = lldb.SBProcess.eBroadcastBitStateChanged |
> > lldb.SBProcess.eBroadcastBitSTDOUT | lldb.SBProcess.eBroadcastBitSTDERR |
> > lldb.SBProcess.eBroadcastBitInterrupt
> > broadcaster.AddListener(self.listener, mask)
> >
> > def run(self):
> > print ' Listening Thread ID: %d' % thread.get_ident()
> > while not self.should_quit:
> > event = lldb.SBEvent()
> > if self.listener.WaitForEvent(1, event):
> > if lldb.SBTarget.EventIsTargetEvent(event):
> > self._handle_target_event(event)
> > elif lldb.SBProcess.EventIsProcessEvent(event):
> > self._handle_process_event(event)
> > elif lldb.SBBreakpoint.EventIsBreakpointEvent(event):
> > self._handle_breakpoint_event(event)
> > elif lldb.SBThread.EventIsThreadEvent(event):
> > self._handle_thread_event(event)
> > else:
> > self._handle_unknown_event(event)
> > print ' Exiting listener thread'
> >
> > def _handle_target_event(self, event):
> > event_type = event.GetType()
> > print 'Target event: %s' %
> target_event_type_to_name_map[event_type]
> >
> > def _handle_process_event(self, event):
> > if lldb.SBProcess.GetRestartedFromEvent(event):
> > print 'Non stopping event: %s' % str(event)
> > return
> > process = lldb.SBProcess.GetProcessFromEvent(event)
> > event_type = event.GetType()
> > print 'Process event: %s, %s' %
> > (process_event_type_to_name_map[event_type],
> > process_state_name_map[process.state])
> > if process.state == lldb.eStateExited:
> > self.should_quit = True
> > elif process.state == lldb.eStateStopped:
> > if self._stopped_sigal:
> > self._stopped_sigal.set()
> > else:
> > if self._running_signal:
> > self._running_signal.set()
> >
> > thread = process.selected_thread
> > print 'Stop reason: %d' % thread.GetStopReason()
> > if event_type == lldb.SBProcess.eBroadcastBitSTDOUT:
> > print 'Stdout:'
> > while True:
> >     output = process.GetSTDOUT(1024)
> > if output is None or len(output) == 0:
> > break
> > stdout.write(output)
> >
> > def _handle_breakpoint_event(self, event):
> > breakpoint = lldb.SBBreakpoint.GetBreakpointFromEvent(event)
> > event_type =
> > lldb.SBBreakpoint.GetBreakpointEventTypeFromEvent(event)
> > print 'Breakpoint event: [%s] %s ' % (
> > breakpoint_event_type_to_name_map[event_type],
> > self._get_description_from_object(breakpoint))
> >
> > def _handle_unknown_event(self, event):
> > print('Unknown event: %d %s %s' % (
> > event.GetType(),
> > lldb.SBEvent.GetCStringFromEvent(event),
> > self._get_description_from_object(event)))
> >
> > def _get_description_from_object(self, lldb_object):
> > description_stream = lldb.SBStream()
> > lldb_object.GetDescription(description_stream)
> > return description_stream.GetData()
> >
> >
> >
> >
> >
> > On Sun, Mar 20, 2016 at 7:10 AM, Pavel Labath  wrote:
> >>
> >> If you send me a small repro case, I can try to look at why is Linux
> >> different here.
> >>
> >> On 19 March 2016 at 00:46, Jim Ingham via lldb-dev
> >>  wrote:
> >> > All this logic is handled in Process::HandleProcessStateChangedEvent
> >> > (see around line 1215 in Process.cpp)  You shouldn’t have to
> reimplement the
> >> > logic for setting the selected thread unless you don’t like our
&

Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description

[Jeffrey Tan via lldb-dev]

ase, a std::string might contain bogus data and the bytes
>>> might not make sense. So you always have to be prepared for bad data.
>>>
>>> If we look at:
>>>
>>>  store_ = {
>>> = {
>>>  small_ = "www"
>>>  ml_ = (data_ =
>>>
>>> "��UH\x89�H�}�H\x8bE�]ÐUH\x89�H��H\x89}�H\x8bE�H\x89��~\xb4��\x90��UH\x89�SH\x83�H\x89}�H�u�H�E�H���\x9e���H\x8b\x18H\x8bE�H���O\xb4��H\x89ƿ\b",
>>> size_ = 0, capacity_ = 1441151880758558720)
>>>}
>>>  }
>>> }
>>>
>>> We can see the "size_" is zero, and capacity_ is 1441151880758558720
>>> (which is 0x1400). "data_" seems to be some random pointer.
>>>
>>> On MacOSX, we have a special formatting code that displays std::string
>>> in CPlusPlusLanguage.cpp that gets installed in the LoadLibCxxFormatters()
>>> or LoadLibStdcppFormatters() functions with code like:
>>>
>>>lldb::TypeSummaryImplSP std_string_summary_sp(new
>>> CXXFunctionSummaryFormat(stl_summary_flags,
>>> lldb_private::formatters::LibcxxStringSummaryProvider, "std::string summary
>>> provider"));
>>>
>>> cpp_category_sp->GetTypeSummariesContainer()->Add(ConstString("std::__1::string"),
>>> std_string_summary_sp);
>>>
>>> Special flags are set on std::string to say "don't show children of this
>>> and just show a summary" So if a std::string contained "hello". So for the
>>> following code:
>>>
>>> std::string h ("hello");
>>>
>>> You should just see:
>>>
>>> (lldb) fr var h
>>> (std::__1::string) h = "hello"
>>>
>>> If you take a look at the normal value in the raw we see:
>>>
>>> (lldb) fr var --raw h
>>> (std::__1::string) h = {
>>>  __r_ = {
>>>std::__1::__libcpp_compressed_pair_imp>> std::__1::char_traits, std::__1::allocator >::__rep,
>>> std::__1::allocator, 2> = {
>>>  __first_ = {
>>> = {
>>>  __l = {
>>>__cap_ = 122511465736202
>>>__size_ = 0
>>>__data_ = 0x
>>>  }
>>>  __s = {
>>> = {
>>>  __size_ = '\n'
>>>  __lx = '\n'
>>>}
>>>__data_ = {
>>>  [0] = 'h'
>>>  [1] = 'e'
>>>  [2] = 'l'
>>>  [3] = 'l'
>>>  [4] = 'o'
>>>  [5] = '\0'
>>>  [6] = '\0'
>>>  [7] = '\0'
>>>  [8] = '\0'
>>>  [9] = '\0'
>>>  [10] = '\0'
>>>  [11] = '\0'
>>>  [12] = '\0'
>>>  [13] = '\0'
>>>  [14] = '\0'
>>>  [15] = '\0'
>>>  [16] = '\0'
>>>  [17] = '\0'
>>>  [18] = '\0'
>>>  [19] = '\0'
>>>  [20] = '\0'
>>>  [21] = '\0'
>>>  [22] = '\0'
>>>}
>>>  }
>>>  __r = {
>>>__words = {
>>>  [0] = 122511465736202
>>>  [1] = 0
>>>  [2] = 0
>>>}
>>>  }
>>>}
>>>  }
>>>}
>>>  }
>>> }
>>>
>>> So the main question is why are our "std::string" formatters not kicking
>>> in for you. That comes down to a typename match, or the format of the
>>> string isn't what the formatter is expecting.
>>>
>>> But again, since you std::string can contain anything, you will need to
>>> escape any and all text that is encoded into JSON to ensure it doesn't
>>> contain anything JSON can't deal with.
>>>
>>> On Mar 27, 2016, at 9:20 PM, Jeffrey Tan via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
>>> Thanks Siva. All the DW_TAG_member related errors seems to go away after
>>> patching with your fix. The current problem is 

Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description

[Jeffrey Tan via lldb-dev]

he variable
>>>> in order to grab a summary
>>>> In your example, your std::string exposes a layout that we are not
>>>> handling - hence we bail out of the formatter and we fall back to the raw
>>>> view
>>>>
>>>> If you want pretty printing to work, you’ll need to write a data
>>>> formatter
>>>>
>>>> There are a few avenues. The obvious easy one is to extend the existing
>>>> std::string formatter to recognize your type’s internal layout.
>>>> If one were signing up for more infrastructure work, they could decide
>>>> to try and detect shared library loads and load formatters that match with
>>>> whatever libraries are being loaded.
>>>>
>>>> On Mar 28, 2016, at 9:47 AM, Greg Clayton via lldb-dev <
>>>> lldb-dev@lists.llvm.org> wrote:
>>>>
>>>> So you need to be prepared to escape any text that can have special
>>>> characters. A "std::string" or any container can contain special
>>>> characters. If you are encoding stuff into JSON, you will either need to
>>>> escape any special characters, or hex encode the string into ASCII hex
>>>> bytes.
>>>>
>>>> In debuggers we often get bogus data because variables are not
>>>> initialized, but the compiler tells us that a variable is valid in address
>>>> range [0x1000-0x2000), but it actually is [0x1200-0x2000). If we read a
>>>> variable in this case, a std::string might contain bogus data and the bytes
>>>> might not make sense. So you always have to be prepared for bad data.
>>>>
>>>> If we look at:
>>>>
>>>>  store_ = {
>>>> = {
>>>>  small_ = "www"
>>>>  ml_ = (data_ =
>>>>
>>>> "��UH\x89�H�}�H\x8bE�]ÐUH\x89�H��H\x89}�H\x8bE�H\x89��~\xb4��\x90��UH\x89�SH\x83�H\x89}�H�u�H�E�H���\x9e���H\x8b\x18H\x8bE�H���O\xb4��H\x89ƿ\b",
>>>> size_ = 0, capacity_ = 1441151880758558720)
>>>>}
>>>>  }
>>>> }
>>>>
>>>> We can see the "size_" is zero, and capacity_ is 1441151880758558720
>>>> (which is 0x1400). "data_" seems to be some random pointer.
>>>>
>>>> On MacOSX, we have a special formatting code that displays std::string
>>>> in CPlusPlusLanguage.cpp that gets installed in the LoadLibCxxFormatters()
>>>> or LoadLibStdcppFormatters() functions with code like:
>>>>
>>>>lldb::TypeSummaryImplSP std_string_summary_sp(new
>>>> CXXFunctionSummaryFormat(stl_summary_flags,
>>>> lldb_private::formatters::LibcxxStringSummaryProvider, "std::string summary
>>>> provider"));
>>>>
>>>> cpp_category_sp->GetTypeSummariesContainer()->Add(ConstString("std::__1::string"),
>>>> std_string_summary_sp);
>>>>
>>>> Special flags are set on std::string to say "don't show children of
>>>> this and just show a summary" So if a std::string contained "hello". So for
>>>> the following code:
>>>>
>>>> std::string h ("hello");
>>>>
>>>> You should just see:
>>>>
>>>> (lldb) fr var h
>>>> (std::__1::string) h = "hello"
>>>>
>>>> If you take a look at the normal value in the raw we see:
>>>>
>>>> (lldb) fr var --raw h
>>>> (std::__1::string) h = {
>>>>  __r_ = {
>>>>std::__1::__libcpp_compressed_pair_imp>>> std::__1::char_traits, std::__1::allocator >::__rep,
>>>> std::__1::allocator, 2> = {
>>>>  __first_ = {
>>>> = {
>>>>  __l = {
>>>>__cap_ = 122511465736202
>>>>__size_ = 0
>>>>__data_ = 0x
>>>>  }
>>>>  __s = {
>>>> = {
>>>>  __size_ = '\n'
>>>>  __lx = '\n'
>>>>}
>>>>__data_ = {
>>>>  [0] = 'h'
>>>>  [1] = 'e'
>>>>  [2] = 'l'
>>>>  [3] = 'l'
>>>>  [4] = 'o'
>>>>  [5] = '\0'
>>>>  [6] = '\0'
>>>>  

Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description

[Jeffrey Tan via lldb-dev]

000). "data_" seems to be some random pointer.
>>>>>
>>>>> On MacOSX, we have a special formatting code that displays std::string
>>>>> in CPlusPlusLanguage.cpp that gets installed in the LoadLibCxxFormatters()
>>>>> or LoadLibStdcppFormatters() functions with code like:
>>>>>
>>>>>lldb::TypeSummaryImplSP std_string_summary_sp(new
>>>>> CXXFunctionSummaryFormat(stl_summary_flags,
>>>>> lldb_private::formatters::LibcxxStringSummaryProvider, "std::string 
>>>>> summary
>>>>> provider"));
>>>>>
>>>>> cpp_category_sp->GetTypeSummariesContainer()->Add(ConstString("std::__1::string"),
>>>>> std_string_summary_sp);
>>>>>
>>>>> Special flags are set on std::string to say "don't show children of
>>>>> this and just show a summary" So if a std::string contained "hello". So 
>>>>> for
>>>>> the following code:
>>>>>
>>>>> std::string h ("hello");
>>>>>
>>>>> You should just see:
>>>>>
>>>>> (lldb) fr var h
>>>>> (std::__1::string) h = "hello"
>>>>>
>>>>> If you take a look at the normal value in the raw we see:
>>>>>
>>>>> (lldb) fr var --raw h
>>>>> (std::__1::string) h = {
>>>>>  __r_ = {
>>>>>std::__1::__libcpp_compressed_pair_imp>>>> std::__1::char_traits, std::__1::allocator >::__rep,
>>>>> std::__1::allocator, 2> = {
>>>>>  __first_ = {
>>>>> = {
>>>>>  __l = {
>>>>>__cap_ = 122511465736202
>>>>>__size_ = 0
>>>>>__data_ = 0x
>>>>>  }
>>>>>  __s = {
>>>>> = {
>>>>>  __size_ = '\n'
>>>>>  __lx = '\n'
>>>>>}
>>>>>__data_ = {
>>>>>  [0] = 'h'
>>>>>  [1] = 'e'
>>>>>  [2] = 'l'
>>>>>  [3] = 'l'
>>>>>  [4] = 'o'
>>>>>  [5] = '\0'
>>>>>  [6] = '\0'
>>>>>  [7] = '\0'
>>>>>  [8] = '\0'
>>>>>  [9] = '\0'
>>>>>  [10] = '\0'
>>>>>  [11] = '\0'
>>>>>  [12] = '\0'
>>>>>  [13] = '\0'
>>>>>  [14] = '\0'
>>>>>  [15] = '\0'
>>>>>  [16] = '\0'
>>>>>  [17] = '\0'
>>>>>  [18] = '\0'
>>>>>  [19] = '\0'
>>>>>  [20] = '\0'
>>>>>  [21] = '\0'
>>>>>  [22] = '\0'
>>>>>}
>>>>>  }
>>>>>  __r = {
>>>>>__words = {
>>>>>  [0] = 122511465736202
>>>>>  [1] = 0
>>>>>  [2] = 0
>>>>>}
>>>>>  }
>>>>>}
>>>>>  }
>>>>>}
>>>>>  }
>>>>> }
>>>>>
>>>>> So the main question is why are our "std::string" formatters not
>>>>> kicking in for you. That comes down to a typename match, or the format of
>>>>> the string isn't what the formatter is expecting.
>>>>>
>>>>> But again, since you std::string can contain anything, you will need
>>>>> to escape any and all text that is encoded into JSON to ensure it doesn't
>>>>> contain anything JSON can't deal with.
>>>>>
>>>>> On Mar 27, 2016, at 9:20 PM, Jeffrey Tan via lldb-dev <
>>>>> lldb-dev@lists.llvm.org> wrote:
>>>>>
>>>>> Thanks Siva. All the DW_TAG_member related errors seems to go away
>>>>> after patching with your fix. The current problem is handling the 
>>>>> decoding.
>>>>>
>>>>> Here is the correct decoding from gdb whic might be useful:
>>>>> (gdb) p corpus
>>>>> $3 = (const std::string &) @0x7fd133cfb888: {
>>>>>  static npos = 18446744073709551615, store_ = {
>>>>>static kIsLittleEndian = ,
>>>>>static kIsBigEndian = , {
>>>>>  small_ = "www", '\000' , "\024", ml_ = {
>>>>>data_ = 0x77 >>>> folly::fibers::Baton::waitFiber::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1},
>>>>> void>::type::value_type
>>>>> folly::fibers::await::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1}>(folly::fibers::FirstArgOf&&)::{lambda()#1}>(folly::fibers::FiberManager&,
>>>>> folly::fibers::FirstArgOf::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1},
>>>>> void>::type::value_type
>>>>> folly::fibers::await::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1}>(folly::fibers::FirstArgOf&&)::{lambda()#1},
>>>>> void>::type::value_type)::{lambda(folly::fibers::Fiber&)#1}*>() const+25>
>>>>> "\311\303UH\211\345H\211}\370H\213E\370]ÐUH\211\345H\203\354\020H\211}\370H\213E\370H\211\307\350~\264\312\377\220\311\303UH\211\345SH\203\354\030H\211}\350H\211u\340H\213E\340H\211\307\350\236\377\377\377H\213\030H\213E\350H\211\307\350O\264\312\377H\211ƿ\b",
>>>>> size_ = 0,
>>>>>capacity_ = 1441151880758558720
>>>>>
>>>>> Utf-16 does not seem to decode it, while 'latin-1' does:
>>>>>
>>>>> '\xc9'.decode('utf-16')
>>>>>
>>>>> Traceback (most recent call last):
>>>>>  File "", line 1, in 
>>>>>  File
>>>>> "/mnt/gvfs/third-party2/python/55c1fd79d91c77c95932db31a4769919611c12bb/2.7.8/centos6-native/da39a3e/lib/python2.7/encodings/utf_16.py",
>>>>> line 16, in decode
>>>>>return codecs.utf_16_decode(input, errors, True)
>>>>> UnicodeDecodeError: 'utf16' codec can't decode byte 0xc9 in position
>>>>> 0: truncated data
>>>>>
>>>>> '\xc9'.decode('latin-1')
>>>>>
>>>>> u'\xc9'
>>>>>
>>>>> Instead of guessing what kind of decoding I should use, I would use
>>>>> 'ensure_ascii=False' to prevent the crash for now.
>>>>>
>>>>> I tried to reproduce this crash, but it seems that the crash might be
>>>>> related with some internal stl implementation we are using. I will see if 
>>>>> I
>>>>> can narrow down to a small repro later.
>>>>>
>>>>> Thanks
>>>>> Jeffrey
>>>>>
>>>>> On Sun, Mar 27, 2016 at 2:49 PM, Siva Chandra 
>>>>> wrote:
>>>>> On Sat, Mar 26, 2016 at 11:58 PM, Jeffrey Tan 
>>>>> wrote:
>>>>>
>>>>> Btw: after patching with Siva's fix http://reviews.llvm.org/D18008,
>>>>> the
>>>>> first field 'small_' is fixed, however the second field 'ml_' still
>>>>> emits
>>>>> garbage:
>>>>>
>>>>> (lldb) fr v corpus
>>>>> (const string &const) corpus = error: summary string parsing error: {
>>>>>  store_ = {
>>>>> = {
>>>>>  small_ = "www"
>>>>>  ml_ = (data_ =
>>>>>
>>>>> "��UH\x89�H�}�H\x8bE�]ÐUH\x89�H��H\x89}�H\x8bE�H\x89��~\xb4��\x90��UH\x89�SH\x83�H\x89}�H�u�H�E�H���\x9e���H\x8b\x18H\x8bE�H���O\xb4��H\x89ƿ\b",
>>>>> size_ = 0, capacity_ = 1441151880758558720)
>>>>>}
>>>>>  }
>>>>> }
>>>>>
>>>>>
>>>>> Do you still see the DW_TAG_member related error?
>>>>>
>>>>> A wild (and really wild at that) guess: Is it utf16 data that is being
>>>>> decoded as utf8?
>>>>>
>>>>> As David Blaikie mentioned on the other thread, it would really help
>>>>> if you provide us with a minimal example to repro this. Atleast, repro
>>>>> instructions.
>>>>>
>>>>> ___
>>>>> lldb-dev mailing list
>>>>> lldb-dev@lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>>
>>>>>
>>>>> ___
>>>>> lldb-dev mailing list
>>>>> lldb-dev@lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>> *- Enrico*
>>>>> 📩 egranata@.com ☎️ 27683
>>>>>
>>>>>
>>>>
>>>>
>>>> Thanks,
>>>> *- Enrico*
>>>> 📩 egranata@.com ☎️ 27683
>>>>
>>>>
>>>
>>>
>>> Thanks,
>>> *- Enrico*
>>> 📩 egranata@.com ☎️ 27683
>>>
>>>
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description

[Jeffrey Tan via lldb-dev]

re being loaded.
>>>>>>
>>>>>> On Mar 28, 2016, at 9:47 AM, Greg Clayton via lldb-dev <
>>>>>> lldb-dev@lists.llvm.org> wrote:
>>>>>>
>>>>>> So you need to be prepared to escape any text that can have special
>>>>>> characters. A "std::string" or any container can contain special
>>>>>> characters. If you are encoding stuff into JSON, you will either need to
>>>>>> escape any special characters, or hex encode the string into ASCII hex
>>>>>> bytes.
>>>>>>
>>>>>> In debuggers we often get bogus data because variables are not
>>>>>> initialized, but the compiler tells us that a variable is valid in 
>>>>>> address
>>>>>> range [0x1000-0x2000), but it actually is [0x1200-0x2000). If we read a
>>>>>> variable in this case, a std::string might contain bogus data and the 
>>>>>> bytes
>>>>>> might not make sense. So you always have to be prepared for bad data.
>>>>>>
>>>>>> If we look at:
>>>>>>
>>>>>>  store_ = {
>>>>>> = {
>>>>>>  small_ = "www"
>>>>>>  ml_ = (data_ =
>>>>>>
>>>>>> "��UH\x89�H�}�H\x8bE�]ÐUH\x89�H��H\x89}�H\x8bE�H\x89��~\xb4��\x90��UH\x89�SH\x83�H\x89}�H�u�H�E�H���\x9e���H\x8b\x18H\x8bE�H���O\xb4��H\x89ƿ\b",
>>>>>> size_ = 0, capacity_ = 1441151880758558720)
>>>>>>}
>>>>>>  }
>>>>>> }
>>>>>>
>>>>>> We can see the "size_" is zero, and capacity_ is 1441151880758558720
>>>>>> (which is 0x1400). "data_" seems to be some random pointer.
>>>>>>
>>>>>> On MacOSX, we have a special formatting code that displays
>>>>>> std::string in CPlusPlusLanguage.cpp that gets installed in the
>>>>>> LoadLibCxxFormatters() or LoadLibStdcppFormatters() functions with code
>>>>>> like:
>>>>>>
>>>>>>lldb::TypeSummaryImplSP std_string_summary_sp(new
>>>>>> CXXFunctionSummaryFormat(stl_summary_flags,
>>>>>> lldb_private::formatters::LibcxxStringSummaryProvider, "std::string 
>>>>>> summary
>>>>>> provider"));
>>>>>>
>>>>>> cpp_category_sp->GetTypeSummariesContainer()->Add(ConstString("std::__1::string"),
>>>>>> std_string_summary_sp);
>>>>>>
>>>>>> Special flags are set on std::string to say "don't show children of
>>>>>> this and just show a summary" So if a std::string contained "hello". So 
>>>>>> for
>>>>>> the following code:
>>>>>>
>>>>>> std::string h ("hello");
>>>>>>
>>>>>> You should just see:
>>>>>>
>>>>>> (lldb) fr var h
>>>>>> (std::__1::string) h = "hello"
>>>>>>
>>>>>> If you take a look at the normal value in the raw we see:
>>>>>>
>>>>>> (lldb) fr var --raw h
>>>>>> (std::__1::string) h = {
>>>>>>  __r_ = {
>>>>>>std::__1::__libcpp_compressed_pair_imp>>>>> std::__1::char_traits, std::__1::allocator >::__rep,
>>>>>> std::__1::allocator, 2> = {
>>>>>>  __first_ = {
>>>>>> = {
>>>>>>  __l = {
>>>>>>__cap_ = 122511465736202
>>>>>>__size_ = 0
>>>>>>__data_ = 0x
>>>>>>  }
>>>>>>  __s = {
>>>>>> = {
>>>>>>  __size_ = '\n'
>>>>>>  __lx = '\n'
>>>>>>}
>>>>>>__data_ = {
>>>>>>  [0] = 'h'
>>>>>>  [1] = 'e'
>>>>>>  [2] = 'l'
>>>>>>  [3] = 'l'
>>>>>>  [4] = 'o'
>>>>>>  [5] = '\0'
>>>>>>  [6]

[lldb-dev] How to get function name without arguments type/value/name?

[Jeffrey Tan via lldb-dev]

Hi,

I call SBFrame.name to get function name and display in our debugger
callstack window. However, this seems to include arguments types
sometimes.(Btw: why it includes arguments types for subFunction but not
main() in screenshot?)

[image: Inline image 1]

This is fine for small function, but can be really long if the function has
a lot of arguments and the arguments are of template type.

Is there any way to only get the function name without arguments types?

I have tried ""settings set frame-format [..]" " which seems to only apply
to "bt" command.
I have tried SBFrame.function.name the same result.

Did I miss anything?
Jeffrey
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description

[Jeffrey Tan via lldb-dev]

pename, then they try to inspect the
>>>>>>> variable in order to grab a summary
>>>>>>> In your example, your std::string exposes a layout that we are not
>>>>>>> handling - hence we bail out of the formatter and we fall back to the 
>>>>>>> raw
>>>>>>> view
>>>>>>>
>>>>>>> If you want pretty printing to work, you’ll need to write a data
>>>>>>> formatter
>>>>>>>
>>>>>>> There are a few avenues. The obvious easy one is to extend the
>>>>>>> existing std::string formatter to recognize your type’s internal layout.
>>>>>>> If one were signing up for more infrastructure work, they could
>>>>>>> decide to try and detect shared library loads and load formatters that
>>>>>>> match with whatever libraries are being loaded.
>>>>>>>
>>>>>>> On Mar 28, 2016, at 9:47 AM, Greg Clayton via lldb-dev <
>>>>>>> lldb-dev@lists.llvm.org> wrote:
>>>>>>>
>>>>>>> So you need to be prepared to escape any text that can have special
>>>>>>> characters. A "std::string" or any container can contain special
>>>>>>> characters. If you are encoding stuff into JSON, you will either need to
>>>>>>> escape any special characters, or hex encode the string into ASCII hex
>>>>>>> bytes.
>>>>>>>
>>>>>>> In debuggers we often get bogus data because variables are not
>>>>>>> initialized, but the compiler tells us that a variable is valid in 
>>>>>>> address
>>>>>>> range [0x1000-0x2000), but it actually is [0x1200-0x2000). If we read a
>>>>>>> variable in this case, a std::string might contain bogus data and the 
>>>>>>> bytes
>>>>>>> might not make sense. So you always have to be prepared for bad data.
>>>>>>>
>>>>>>> If we look at:
>>>>>>>
>>>>>>>  store_ = {
>>>>>>> = {
>>>>>>>  small_ = "www"
>>>>>>>  ml_ = (data_ =
>>>>>>>
>>>>>>> "��UH\x89�H�}�H\x8bE�]ÐUH\x89�H��H\x89}�H\x8bE�H\x89��~\xb4��\x90��UH\x89�SH\x83�H\x89}�H�u�H�E�H���\x9e���H\x8b\x18H\x8bE�H���O\xb4��H\x89ƿ\b",
>>>>>>> size_ = 0, capacity_ = 1441151880758558720)
>>>>>>>}
>>>>>>>  }
>>>>>>> }
>>>>>>>
>>>>>>> We can see the "size_" is zero, and capacity_ is 1441151880758558720
>>>>>>> (which is 0x1400). "data_" seems to be some random pointer.
>>>>>>>
>>>>>>> On MacOSX, we have a special formatting code that displays
>>>>>>> std::string in CPlusPlusLanguage.cpp that gets installed in the
>>>>>>> LoadLibCxxFormatters() or LoadLibStdcppFormatters() functions with code
>>>>>>> like:
>>>>>>>
>>>>>>>lldb::TypeSummaryImplSP std_string_summary_sp(new
>>>>>>> CXXFunctionSummaryFormat(stl_summary_flags,
>>>>>>> lldb_private::formatters::LibcxxStringSummaryProvider, "std::string 
>>>>>>> summary
>>>>>>> provider"));
>>>>>>>
>>>>>>> cpp_category_sp->GetTypeSummariesContainer()->Add(ConstString("std::__1::string"),
>>>>>>> std_string_summary_sp);
>>>>>>>
>>>>>>> Special flags are set on std::string to say "don't show children of
>>>>>>> this and just show a summary" So if a std::string contained "hello". So 
>>>>>>> for
>>>>>>> the following code:
>>>>>>>
>>>>>>> std::string h ("hello");
>>>>>>>
>>>>>>> You should just see:
>>>>>>>
>>>>>>> (lldb) fr var h
>>>>>>> (std::__1::string) h = "hello"
>>>>>>>
>>>>>>> If you take a look at the normal value in the raw we see:
>>>>>>>
>>>>>>> (lldb) fr var --raw h
>>>>>>> (std::__1::string) h = {
>>>>>>>  __r_ = 

[lldb-dev] Problem of building lldb on Mac

[Jeffrey Tan via lldb-dev]

Hi,

I followed instructions in http://lldb.llvm.org/build.html to build lldb on
Mac.

I opened "*lldb/lldb.xcworkspace*" in Xcode7.3.1, select lldb-tools scheme
and build, I always got build error below. I have tried "brew install
cmake" but the installed cmake version does not match what build script is
looking for.

*Questions:*
Do I suppose to find and download 3.1.2 version of cmake to get this
working? Do I miss anything? Thanks.

...

/bin/sh -c
/Users/jeffreytan/Library/Developer/Xcode/DerivedData/lldb-acenblzastrxbocknmwzltsmlasq/Build/Intermediates/lldb.build/DebugClang/lldb-core.build/Script-261EECA21337D399001D193C.sh


[0/1] Re-running CMake...

/bin/sh: /usr/local/Cellar/cmake/3.1.2/bin/cmake: No such file or directory

FAILED: build.ninja

/usr/local/Cellar/cmake/3.1.2/bin/cmake -H/Users/jeffreytan/local/lldb/llvm
-B/Users/jeffreytan/local/lldb/llvm-build/Debug+Asserts/x86_64

ninja: error: rebuilding 'build.ninja': subcommand failed

Traceback (most recent call last):

  File "/Users/jeffreytan/local/lldb/scripts/Xcode/build-llvm.py", line
340, in 

build_llvm_if_needed()

  File "/Users/jeffreytan/local/lldb/scripts/Xcode/build-llvm.py", line
334, in build_llvm_if_needed

build_llvm(ninja_binary_path)

  File "/Users/jeffreytan/local/lldb/scripts/Xcode/build-llvm.py", line
328, in build_llvm

subprocess.check_call([ninja_binary_path], cwd=cmake_build_dir,
env=cmake_environment())

  File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py",
line 540, in check_call

raise CalledProcessError(retcode, cmd)

subprocess.CalledProcessError: Command
'['/Users/jeffreytan/local/lldb/ninja/ninja']' returned non-zero exit
status 1
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Problem of building lldb on Mac

[Jeffrey Tan via lldb-dev]

Nevermind, I was finally unable to build by "git pull" and
"xcodebuild -configuration Debug"

On Mon, Jun 27, 2016 at 9:55 PM, Jeffrey Tan 
wrote:

> Hi,
>
> I followed instructions in http://lldb.llvm.org/build.html to build lldb
> on Mac.
>
> I opened "*lldb/lldb.xcworkspace*" in Xcode7.3.1, select lldb-tools
> scheme and build, I always got build error below. I have tried "brew
> install cmake" but the installed cmake version does not match what build
> script is looking for.
>
> *Questions:*
> Do I suppose to find and download 3.1.2 version of cmake to get this
> working? Do I miss anything? Thanks.
>
> ...
>
> /bin/sh -c
> /Users/jeffreytan/Library/Developer/Xcode/DerivedData/lldb-acenblzastrxbocknmwzltsmlasq/Build/Intermediates/lldb.build/DebugClang/lldb-core.build/Script-261EECA21337D399001D193C.sh
>
>
> [0/1] Re-running CMake...
>
> /bin/sh: /usr/local/Cellar/cmake/3.1.2/bin/cmake: No such file or directory
>
> FAILED: build.ninja
>
> /usr/local/Cellar/cmake/3.1.2/bin/cmake
> -H/Users/jeffreytan/local/lldb/llvm
> -B/Users/jeffreytan/local/lldb/llvm-build/Debug+Asserts/x86_64
>
> ninja: error: rebuilding 'build.ninja': subcommand failed
>
> Traceback (most recent call last):
>
>   File "/Users/jeffreytan/local/lldb/scripts/Xcode/build-llvm.py", line
> 340, in 
>
> build_llvm_if_needed()
>
>   File "/Users/jeffreytan/local/lldb/scripts/Xcode/build-llvm.py", line
> 334, in build_llvm_if_needed
>
> build_llvm(ninja_binary_path)
>
>   File "/Users/jeffreytan/local/lldb/scripts/Xcode/build-llvm.py", line
> 328, in build_llvm
>
> subprocess.check_call([ninja_binary_path], cwd=cmake_build_dir,
> env=cmake_environment())
>
>   File
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py",
> line 540, in check_call
>
> raise CalledProcessError(retcode, cmd)
>
> subprocess.CalledProcessError: Command
> '['/Users/jeffreytan/local/lldb/ninja/ninja']' returned non-zero exit
> status 1
>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLDB failed to locate source when dwarf symbols are inside compile unit on Linux

[Jeffrey Tan via lldb-dev]

Hi,

O ur company is using Buck(https://buckbuild.com/) to build internal
service. Recently the build team made a change in buck to not merge dwarf
symbols from each object file into final binary so debugger needs to read
source/symbol table from compilation unit itself.
This seems to break the lldb in various aspect:
1. Setting source line breakpoint in library files are not working
2. Callstack did not show the source location well for library frame

I tried latest lldb which this bug still reproduces. Here is the logging
for it:
(lldb) b TaoDataLayer.cpp:50
Target::AddBreakpoint (internal = no) => break_id = 6: file =
'TaoDataLayer.cpp', line = 50, exact_match = 0
*error: Unable to set breakpoint for TaoDataLayer.cpp:50  at file address
0x*
Breakpoint 6: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.


My debugging shows the Address::IsValid() returns false for line start
symbol here because it's file address is 0x:
https://github.com/llvm-mirror/lldb/blob/ceb5f6cd339a4bcd49666158578f883c1ec96663/source/Breakpoint/BreakpointResolver.cpp#L263

It seems that, after locating the symbol for the line_entry, the code below
did not update sc.line_entry pointing to the original line_entry so it
contains the uninitialized 0x value which will fail the
isValid() check later:
https://github.com/llvm-mirror/lldb/blob/26fea9dbbeb3020791cdbc46fbf3cc9d7685d7fd/source/Symbol/CompileUnit.cpp#L375

I tried to fix this by doing "sc.line_entry = line_entry;" before
both resolve_scope branches. This seems to fix the breakpoint but the
callstack and source locator still can't locate the source file correctly
while hitting the breakpoint.

Questions:
1. Is this a known issue? If so, is there any existing fix I can port?
2. If not, does my investigation above sound reasonable? Any
suggestion/direction for callstack and source locator part of fix?

Thanks
Jeffrey
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB failed to locate source when dwarf symbols are inside compile unit on Linux

[Jeffrey Tan via lldb-dev]

Hey Greg, I just confirmed this with our build team. I seem to have
misunderstood the location of debug symbol. It is actually not inside each
individual object file but:

The debug info in dev mode sits in the .debug_* sections of the shared
libraries (we don't use debug fission).

One potential complicating factor is that we relativize the
DW_AT_comp_dirattributes
in the DWARF info, so that it's almost always just a long reference to the
current working directory (e.g. .///).


I do not know why this(symbol in shared library) would cause the bug though.


Jeffrey

On Mon, Jan 9, 2017 at 1:57 PM, Greg Clayton  wrote:

> Comments below.
>
> On Jan 9, 2017, at 1:10 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi,
>
> O ur company is using Buck(https://buckbuild.com/) to build internal
> service. Recently the build team made a change in buck to not merge dwarf
> symbols from each object file into final binary so debugger needs to read
> source/symbol table from compilation unit itself.
>
>
> How are debug symbols expected to be found? Is fission being used where
> the DWARF for each compile unit is in .dwo files and the main executable
> has skeleton DWARF? I will skip all other questions until we know more
> about how and where the DWARF is.
>
> Greg Clayton
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] How to set source line breakpoint using BreakpointCreateByLocation?

[Jeffrey Tan via lldb-dev]

Hi,

I am writing a python script to set source line breakpoint in ObjC on Mac
OSX.
But 
self.debugger.GetSelectedTarget().BreakpointCreateByLocation("EATAnimatedView.m",
line) always fail. Any ideas?

Also, can I use full path instead of file basename? In lldb, I found "b
/Users/jeffreytan/fbsource/fbobjc/Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m:21"
will fail to bind but "b EATAnimatedView.m:21" will succeed.

Traceback (most recent call last):
  File
"/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/chromedebugger.py",
line 69, in _generate_response
params=message.get('params', {}),
  File
"/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/handler.py",
line 42, in handle
return self._domains[domain_name].handle(method_name, params)
  File
"/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/handler.py",
line 106, in handle
return self._handlers[method](params)
  File
"/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/handler.py",
line 56, in _handler_wrapper
ret = func(self, params)
  File
"/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/debugger.py",
line 248, in setBreakpointByUrl
int(params['lineNumber']) + 1)
  File
"/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/debugger.py",
line 283, in _set_breakpoint_by_filespec
breakpoint =
self.debugger.GetSelectedTarget().BreakpointCreateByLocation(filespec, line)
  File
"/Applications/Xcode.app/Contents/Developer/../SharedFrameworks/LLDB.framework/Resources/Python/lldb/__init__.py",
line 8650, in BreakpointCreateByLocation
return _lldb.SBTarget_BreakpointCreateByLocation(self, *args)
NotImplementedError: Wrong number of arguments for overloaded function
'SBTarget_BreakpointCreateByLocation'.
  Possible C/C++ prototypes are:
BreakpointCreateByLocation(lldb::SBTarget *,char const *,uint32_t)
BreakpointCreateByLocation(lldb::SBTarget *,lldb::SBFileSpec const
&,uint32_t)
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev