> On Jun 25, 2015, at 10:36 AM, Eugene Birukov <[email protected]> wrote:
>
> Hi,
>
> 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
}
else
{
// 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...
Greg Clayton
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
