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

2016-04-08 Thread Pavel Labath via lldb-dev
Ok, so the reason for this behavior seems to be that the process hits two breakpoints simultaneously: - the breakpoint you have set and you are expecting to hit - an internal shared library breakpoint we use to get notified of new shared libraries * thread #1: tid = 33390, 0x7ff7dcd9f970

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

2016-03-20 Thread Jeffrey Tan via lldb-dev
Thanks guys. I tried our IDE against a sample multithreading program on Mac, it correctly switches selected thread to the worker thread that triggers breakpoint, while on Linux(CentOS release 6.7) it failed to do that. Repro code: *=Output**=*

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

2016-03-19 Thread Jim Ingham via lldb-dev
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

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

2016-03-18 Thread 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 >

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

2016-03-18 Thread 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

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

2016-03-18 Thread 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,

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

2016-03-18 Thread 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

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

2016-03-18 Thread 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

[lldb-dev] Weird stop stack while hitting breakpoint

2016-03-18 Thread 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

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

2016-03-18 Thread 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