[lldb-dev] C++ API get stray process stopped event
gclayton at apple.com
Thu Jun 25 16:14:17 PDT 2015
> On Jun 25, 2015, at 10:36 AM, Eugene Birukov <eugenebi at hotmail.com> wrote:
> I am running on Linux Ubuntu 14.04 with lldb-4.7 I built from sources about a month ago.
> My C++ debugger does pretty much the following:
> • Initializes LLDB, sets it to async mode
> • Gets listener from debugger, subscribes for process and target events
> • Sets a few breakpoints
> • Waits for event on the listener
> • If event is a process event
> • If event type is eBroadcastBitSTDOUT or eBroadcastBitSTERR
> • call SBDebugger::HandleProcessEvent() to get it printed
> • else if process state is eStateStopped
> • scan all the target threads and checks their stop reason, registers, etc.
> • call SBProcess::Continue()
> • Loop to 4
> Now, the program behavior varies - so it might be I am doing something wrong...
> One version of the program always gets stray stopped event in the very beginning after reporting several module loads. In this case it has only one thread yet and the thread stop reason is eStopReasonNone. when it happens, I have to skip calling SBProcess::Continue() - i.e. just ignore this event as if the target state was eStateRunning and reissue wait for event. This is a bit annoying but detection and workaround are simple.
You must check to see if a eStateStopped event was restarted:
lldb::SBEvent event = ...; // Get event somehow
lldb::StateType state = SBProcess::GetStateFromEvent(event);
if (state == eStateStopped)
if (SBProcess::GetRestartedFromEvent (event))
// Ignore this eStateStopped event, as the process already continued
// Process the stop event.
> Another version of the program does not subscribe for target events. It often works smooth, but once in a while gets stray stopped event and the thread state is eStopReasonTrace. I should not call SBProcess::Continue() in this case too. Now the problem is that I do turn on tracing sometimes, and if it is genuine trace event I have to call continue.
> Any advice - how to investigate this problem - if it is my bug or something in LLDB?
Check for restarted events and let me know if you still see problems after you ignore restarts...
More information about the lldb-dev