Thank you Pavel! That's interesting.
Not that urgent, I have a workaround for this issue. For the inferior, I
just copied some random multithreading code from internet to demonstrate
this issue, definitely a good way exit main thread :-).
Btw: I was surprised on Mac/Linux the whole process is still
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
ld-li
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**=*
Launch
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 log
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
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
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 thr
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_as
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
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,
howeve
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
reas
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 fo
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 a
13 matches
Mail list logo
