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

[Greg Clayton via lldb-dev]

You iterate over all the threads and ask each thread what its stop reason is.

> On Mar 18, 2016, at 4:25 PM, Jeffrey Tan via lldb-dev 
>  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 
>>  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.GetType()
>> if event_type == lldb.SBProcess.eBroadcastBitSTDOUT:
>> # Read stdout from inferior.
>> process_output = ''
>> while True:
>> output_part = process.GetSTDOUT(1024)
>>

Re: [lldb-dev] "target modules load" and breakpoints not working correctly

[Ted Woodward via lldb-dev]

I found why the load addresses are getting dropped. When I do "target modules 
load", it calls SectionLoadList::SetSectionLoadAddress(), setting the new load 
address for each section. Then when I attach, 
DynamicLoaderHexagonDYLD::DidAttach() calls 
DynamicLoaderHexagonDYLD::UpdateLoadedSections(), which calls 
Target::SetSectionLoadAddress() for each section, resetting the load address to 
the address in the relevant file.

If I remove the call to Target::SetSectionLoadAddress(), I can't hit 
breakpoints. So I need this, but I think I should only do this if the section 
isn't already loaded.


How do I tell if a section is already loaded?

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


-Original Message-
From: Greg Clayton [mailto:gclay...@apple.com] 
Sent: Friday, March 18, 2016 4:32 PM
To: Ted Woodward 
Cc: LLDB 
Subject: Re: [lldb-dev] "target modules load" and breakpoints not working 
correctly

SectionLoadList::SetSectionLoadAddress() in SectionLoadList.cpp

> On Mar 18, 2016, at 1:54 PM, Ted Woodward  wrote:
> 
> I don't see anything in the packet log that would cause the change. Most of 
> the interesting packets (like qShlibInfoAddr, qProcessInfo or qHostInfo) 
> return an empty reply.
> 
> Where should I set a breakpoint to see the load addresses moving?
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
> a Linux Foundation Collaborative Project
> 
> 
> -Original Message-
> From: Greg Clayton [mailto:gclay...@apple.com]
> Sent: Friday, March 18, 2016 3:12 PM
> To: Ted Woodward 
> Cc: LLDB 
> Subject: Re: [lldb-dev] "target modules load" and breakpoints not 
> working correctly
> 
> So you will need to find out who is sliding the shared library incorrectly. 
> It might be a packet that is received through the GDB remote protocol, so 
> there might be a bug in your GDB server.
> 
> Greg
> 
>> On Mar 18, 2016, at 11:45 AM, Ted Woodward  
>> wrote:
>> 
>> Your guess is right - the sections moved. Before attaching:
>> 
>> 0x0008 code [0x0003-0x00068d5c)  
>> 0x00011000 0x00038d5c 0x0006 dlopen..text
>> 
>> After attaching:
>> 
>> 0x0008 code [0x0001-0x00048d5c)  
>> 0x00011000 0x00038d5c 0x0006 dlopen..text
>> 
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora 
>> Forum, a Linux Foundation Collaborative Project
>> 
>> -Original Message-
>> From: Greg Clayton [mailto:gclay...@apple.com]
>> Sent: Thursday, March 17, 2016 12:44 PM
>> To: Ted Woodward 
>> Cc: LLDB 
>> Subject: Re: [lldb-dev] "target modules load" and breakpoints not 
>> working correctly
>> 
>> Sounds like something is going wrong when resolving the address. I am 
>> guessing that your sections got unloaded when you attached to your GDB 
>> remote target. So try this:
>> 
>> (lldb) file u:\lldb_test\dlopen
>> Current executable set to 'u:\lldb_test\dlopen' (hexagon).
>> (lldb) target modules load -f dlopen -s 0x2
>> (lldb) b main
>> Breakpoint 1: where = dlopen`main + 24 at dlopen.c:26, address =
>> 0x00030018
>> 
>> Note we got the address correct. Now do a:
>> 
>> (lldb) image dump sections dlopen
>> 
>> Check to make sure all addresses for the sections look good.
>> 
>> Now do:
>> 
>> (lldb) gdb-remote tedwood-ubuntu:5556
>> (lldb) image dump sections dlopen
>> 
>> I am guessing that the sections have been moved...
>> 
>> Let me know what you find.
>> 
>>> On Mar 16, 2016, at 4:28 PM, Ted Woodward via lldb-dev 
>>>  wrote:
>>> 
>>> I’m seeing 2 issues with “target modules load”:
>>> 
>>> 
>>> 
>>> Issue #1: load address is forgotten after a connect:
>>> 
>>> (lldb) file u:\lldb_test\dlopen
>>> Current executable set to 'u:\lldb_test\dlopen' (hexagon).
>>> (lldb) target modules load -f dlopen -s 0x2
>>> (lldb) b main
>>> Breakpoint 1: where = dlopen`main + 24 at dlopen.c:26, address =
>>> 0x00030018
>>> (lldb) gdb-remote tedwood-ubuntu:5556
>>> 
>>> But it’s set the breakpoint at 0x10018 instead of 0x30018:
>>> ProcessGDBRemote::EnableBreakpointSite (size_id = 14) address =
>>> 0x10018 <  14> send packet: $Z0,10018,4#10
>>> <   4> read packet: $#00
>>> Software breakpoints are unsupported <  14> send packet: 
>>> $Z1,10018,4#11
>>> <   6> read packet: $OK#9a
>>> 
>>> (lldb) br l
>>> Current breakpoints:
>>> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>>> 1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00010018, 
>>> resolved, hit count = 0
>>> 
>>> 
>>> 
>>> 
>>> Issue #2: breakpoints on the remote server aren’t updated with a new 

Re: [lldb-dev] Help needed regarding LLDB/MI

[Greg Clayton via lldb-dev]

> On Mar 11, 2016, at 9:30 AM, RISHABH GUPTA via lldb-dev 
>  wrote:
> 
> Hello all,
> 
> I have started using LLDB/MI but there are some commands that are not working 
> .I start the MI in terminal as "lldb-mi-3.6 --interpreter" and then launch 
> the application that  I want to debug but commands like "n" 
> ,"list","continue" ,"step" are not working.There is this error message that 
> gets displayed on giving these commands
> 
> "^error,msg="Driver. Received command 'command_name'. It was not handled. 
> Command 'continue' not in Command Factory"

Was this something you were typing at a "(gdb)" prompt? If not, it sounds like 
your software is using GDB commands instead of using the actual MI commands and 
the best solutions is to fix your software to actually use the MI commands 
instead of sending GDB command interpreter commands.

I believe there is some way to send a gdb command line command, so if you have 
a "(gdb) " prompt, and we will pass the command along to LLDB. 
> 
> I tried looking for  the substitutes of these commands here 
> https://github.com/llvm-mirror/lldb/tree/7535162178eada833e72a5525fc26dcc04e7331e/tools/lldb-mi
>   but could not find any.
> 
> Could anyone please help me out with this?

So check if your IDE is not actually using MI. Your IDE shouldn't send a 
"continue" GDB command interpreter command, but it should send an 
"exec-continue" MI packet since you are using MI. Don't sent a "n" packet, but 
send a "exec-next" packet. Etc...

Let me know what your IDE is doing. 

Greg


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

[lldb-dev] exception "leaks" to debugger for win32

[Carlo Kok via lldb-dev]

When starting a process on Win32 there's an internal exception 
(breakpint) that leaks to the debug caller:

s   'Exception 0x8003 encountered at address 0x7789ccbc'#0

This one is dealt with by the debugger internally but there's still a 
StateType.eStateStopped event for it. On other platforms there's no 
exception like this for the internal start breakpoint (note that actual 
breakpoints after this hit just fine)


--
Carlo Kok
RemObjects Software
___
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]

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.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)
>>
>
> ___
> 

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

[Kate Stone via lldb-dev]

Yes, IIRC it’s the Microsoft compiler that uses a different mangling.
 
Kate Stone k8st...@apple.com 
 Xcode Low Level Tools

> On Mar 18, 2016, at 4:14 PM, Jim Ingham  wrote:
> 
> Note, g++ also uses the Itanium ABI for it’s C++ ABI, so as long as you are 
> on a platform whose primary compiler is gcc and that isn’t very very old, 
> either demangler will be equivalent except for bugs.  The side effects of one 
> or the other are pretty much just that you get a different set of bugs.  So 
> we let the platform owners choose the version they think best.
> 
> Jim
> 
> 
>> On Mar 18, 2016, at 3:54 PM, Kate Stone > > wrote:
>> 
>> Not all platforms use the same C++ name mangling.  Clang follows the Itanium 
>> ABI specification which is what both the built-in LLDB demanglers understand.
>> 
>> Kate Stone k8st...@apple.com 
>>  Xcode Low Level Tools
>> 
>> On Mar 18, 2016, at 3:50 PM, Jeffrey Tan via lldb-dev 
>> > wrote:
>> 
>>> 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 
>>> > > 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 

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

[Jim Ingham via lldb-dev]

The selected thread should be getting set.  You didn’t include the code for 
_send_paused_notification so I don’t know what that does, but if 
SBProcess::GetSelectedThread wasn’t returning a thread with a valid stop 
reason, then there’s some bug somewhere.  That’s all done in generic code, 
however, so I’m not sure how that would happen.

Jim

> On Mar 18, 2016, at 5:23 PM, Jeffrey Tan  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 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 
>>> > 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 
>>> 

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

[Jim Ingham via lldb-dev]

Note, g++ also uses the Itanium ABI for it’s C++ ABI, so as long as you are on 
a platform whose primary compiler is gcc and that isn’t very very old, either 
demangler will be equivalent except for bugs.  The side effects of one or the 
other are pretty much just that you get a different set of bugs.  So we let the 
platform owners choose the version they think best.

Jim


> On Mar 18, 2016, at 3:54 PM, Kate Stone  wrote:
> 
> Not all platforms use the same C++ name mangling.  Clang follows the Itanium 
> ABI specification which is what both the built-in LLDB demanglers understand.
> 
> Kate Stone k8st...@apple.com 
>  Xcode Low Level Tools
> 
> On Mar 18, 2016, at 3:50 PM, Jeffrey Tan via lldb-dev 
> > wrote:
> 
>> 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 
>> > > 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, 
>> > 

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
>>> 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
>>> 

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

[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] "target modules load" and breakpoints not working correctly

[Greg Clayton via lldb-dev]

> On Mar 18, 2016, at 4:37 PM, Ted Woodward  wrote:
> 
> I found why the load addresses are getting dropped. When I do "target modules 
> load", it calls SectionLoadList::SetSectionLoadAddress(), setting the new 
> load address for each section. Then when I attach, 
> DynamicLoaderHexagonDYLD::DidAttach() calls 
> DynamicLoaderHexagonDYLD::UpdateLoadedSections(), which calls 
> Target::SetSectionLoadAddress() for each section, resetting the load address 
> to the address in the relevant file.
> 
> If I remove the call to Target::SetSectionLoadAddress(), I can't hit 
> breakpoints. So I need this, but I think I should only do this if the section 
> isn't already loaded.
> 
> 
> How do I tell if a section is already loaded?

Sounds like you need to fix you DynamicLoaderHexagonDYLD right? No? Is there 
nothing in your program that you can see where things are loaded?

You can ask the section to resolve itself:


lldb::addr_t
SBSection::GetLoadAddress (lldb::SBTarget );

If the return value is LLDB_INVALID_ADDRESS, then the section is not loaded in 
the target.

Greg

> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
> 
> 
> -Original Message-
> From: Greg Clayton [mailto:gclay...@apple.com] 
> Sent: Friday, March 18, 2016 4:32 PM
> To: Ted Woodward 
> Cc: LLDB 
> Subject: Re: [lldb-dev] "target modules load" and breakpoints not working 
> correctly
> 
> SectionLoadList::SetSectionLoadAddress() in SectionLoadList.cpp
> 
>> On Mar 18, 2016, at 1:54 PM, Ted Woodward  
>> wrote:
>> 
>> I don't see anything in the packet log that would cause the change. Most of 
>> the interesting packets (like qShlibInfoAddr, qProcessInfo or qHostInfo) 
>> return an empty reply.
>> 
>> Where should I set a breakpoint to see the load addresses moving?
>> 
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
>> a Linux Foundation Collaborative Project
>> 
>> 
>> -Original Message-
>> From: Greg Clayton [mailto:gclay...@apple.com]
>> Sent: Friday, March 18, 2016 3:12 PM
>> To: Ted Woodward 
>> Cc: LLDB 
>> Subject: Re: [lldb-dev] "target modules load" and breakpoints not 
>> working correctly
>> 
>> So you will need to find out who is sliding the shared library incorrectly. 
>> It might be a packet that is received through the GDB remote protocol, so 
>> there might be a bug in your GDB server.
>> 
>> Greg
>> 
>>> On Mar 18, 2016, at 11:45 AM, Ted Woodward  
>>> wrote:
>>> 
>>> Your guess is right - the sections moved. Before attaching:
>>> 
>>> 0x0008 code [0x0003-0x00068d5c)  
>>> 0x00011000 0x00038d5c 0x0006 dlopen..text
>>> 
>>> After attaching:
>>> 
>>> 0x0008 code [0x0001-0x00048d5c)  
>>> 0x00011000 0x00038d5c 0x0006 dlopen..text
>>> 
>>> --
>>> Qualcomm Innovation Center, Inc.
>>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora 
>>> Forum, a Linux Foundation Collaborative Project
>>> 
>>> -Original Message-
>>> From: Greg Clayton [mailto:gclay...@apple.com]
>>> Sent: Thursday, March 17, 2016 12:44 PM
>>> To: Ted Woodward 
>>> Cc: LLDB 
>>> Subject: Re: [lldb-dev] "target modules load" and breakpoints not 
>>> working correctly
>>> 
>>> Sounds like something is going wrong when resolving the address. I am 
>>> guessing that your sections got unloaded when you attached to your GDB 
>>> remote target. So try this:
>>> 
>>> (lldb) file u:\lldb_test\dlopen
>>> Current executable set to 'u:\lldb_test\dlopen' (hexagon).
>>> (lldb) target modules load -f dlopen -s 0x2
>>> (lldb) b main
>>> Breakpoint 1: where = dlopen`main + 24 at dlopen.c:26, address =
>>> 0x00030018
>>> 
>>> Note we got the address correct. Now do a:
>>> 
>>> (lldb) image dump sections dlopen
>>> 
>>> Check to make sure all addresses for the sections look good.
>>> 
>>> Now do:
>>> 
>>> (lldb) gdb-remote tedwood-ubuntu:5556
>>> (lldb) image dump sections dlopen
>>> 
>>> I am guessing that the sections have been moved...
>>> 
>>> Let me know what you find.
>>> 
 On Mar 16, 2016, at 4:28 PM, Ted Woodward via lldb-dev 
  wrote:
 
 I’m seeing 2 issues with “target modules load”:
 
 
 
 Issue #1: load address is forgotten after a connect:
 
 (lldb) file u:\lldb_test\dlopen
 Current executable set to 'u:\lldb_test\dlopen' (hexagon).
 (lldb) target modules load -f dlopen -s 0x2
 (lldb) b main
 Breakpoint 1: where = dlopen`main + 24 at dlopen.c:26, address =
 0x00030018
 (lldb) gdb-remote tedwood-ubuntu:5556
 
 But it’s set 

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

[Jim Ingham via lldb-dev]

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 
>  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.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

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