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
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**=*
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
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
>
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
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,
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
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
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
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
10 matches
Mail list logo