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 <lldb-dev@lists.llvm.org> wrote: > 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 _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev