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 <gclay...@apple.com> 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 <jing...@apple.com> 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 <jeffrey.fu...@gmail.com> 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, 0x000000000042eacd
>>> biggrep_master_server_async`facebook::biggrep::BigGrepMasterAsync::future_find(this=0x00007f3ea2d74fd0,
>>> corpus=error: summary string parsing error, needle=error: summary string
>>> parsing error, options=0x00007f3e899fc7e0) + 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 <jing...@apple.com> 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 <jeffrey.fu...@gmail.com>
>>>> 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, 0x00007fd7cb2daa83 libc.so.6`__GI_epoll_wait +
>>>> 51, name = 'biggrep_master_'
>>>> * frame #0: 0x00007fd7cb2daa83 libc.so.6`__GI_epoll_wait + 51
>>>> frame #1: 0x000000000271189f
>>>> biggrep_master_server_async`epoll_dispatch(base=0x00007fd7ca970800,
>>>> arg=0x00007fd7ca62c1e0, tv=<unavailable>) + 127 at epoll.c:315
>>>> frame #2: 0x000000000270f6d1
>>>> biggrep_master_server_async`event_base_loop(base=0x00007fd7ca970800,
>>>> flags=<unavailable>) + 225 at event.c:524
>>>> frame #3: 0x00000000025f9378
>>>> biggrep_master_server_async`folly::EventBase::loopBody(this=0x00007fd7ca945180,
>>>> flags=0) + 834 at EventBase.cpp:335
>>>> frame #4: 0x00000000025f900b
>>>> biggrep_master_server_async`folly::EventBase::loop(this=0x00007fd7ca945180)
>>>> + 29 at EventBase.cpp:287
>>>> frame #5: 0x00000000025fa053
>>>> biggrep_master_server_async`folly::EventBase::loopForever(this=0x00007fd7ca945180)
>>>> + 109 at EventBase.cpp:435
>>>> frame #6: 0x0000000001e24b72
>>>> biggrep_master_server_async`apache::thrift::ThriftServer::serve(this=0x00007fd7ca96d710)
>>>> + 110 at ThriftServer.cpp:365
>>>> frame #7: 0x00000000004906bc
>>>> biggrep_master_server_async`facebook::services::ServiceFramework::startFramework(this=0x00007ffc06776140,
>>>> waitUntilStop=true) + 1942 at ServiceFramework.cpp:885
>>>> frame #8: 0x000000000048fe6d
>>>> biggrep_master_server_async`facebook::services::ServiceFramework::go(this=0x00007ffc06776140,
>>>> waitUntilStop=true) + 35 at ServiceFramework.cpp:775
>>>> frame #9: 0x00000000004219a7 biggrep_master_server_async`main(argc=1,
>>>> argv=0x00007ffc067769d8) + 2306 at BigGrepMasterServerAsync.cpp:134
>>>> frame #10: 0x00007fd7cb1ed0f6 libc.so.6`__libc_start_main + 246
>>>> frame #11: 0x0000000000420bfc 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
>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
