[lldb-dev] "step" threading issues

[Greg Clayton]

You should only get one stopped event unless you are hitting a breakpoint that continues your target. In this case the eStateStopped event would be a "restarted" event which can be found out by:

    static bool
    SBProcess::GetRestartedFromEvent (const lldb::SBEvent &event);

This means the program stopped but restarted automatically. You should never see two eStateStopped events in a row, if you are, please try and reproduce on a Mac target and file a bug.

For step into, the stop reason should always be eStopReasonPlanComplete.


On Apr 29, 2013, at 7:33 AM, Carlo Kok <ck at remobjects.com> wrote:

> Op 29-4-2013 15:43, Carlo Kok schreef:
>> Op 29-4-2013 15:40, Carlo Kok schreef:
>>> I'm calling when my users want to "step into" a function:
>>> 
>>> 
>>>     SBThread th= self->m_process.GetSelectedThread();
>>>     th.StepInto();
>>> 
>>> When it's done I get notified in the way of my process listener:
>>> case SBProcess::eBroadcastBitStateChanged:
>>>  int n = self->m_process.GetStateFromEvent (data);
>>>  where n is eStateStopped, however at this point when I read :
>>> 
>>> m_process.GetSelectedThread().GetStopReason() it returns eStopReasonNone
>>> half the time, but never when I'm debugging. This is a simple threaded
>>> all. How should I find out if ti returned from a plan?
>> 
>> I have to add to this that it ONLY happens for Step Into for some reason.
>> 
> 
> And an addition to that: I get several eStateStopped events in sequence when this happens.
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev