[lldb-dev] Weird stop stack while hitting breakpoint

[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 <jeffrey.fudan at 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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160318/89115e55/attachment.html>