[lldb-dev] "step" threading issues

[Carlo Kok]

Op 29-4-2013 22:15, Carlo Kok schreef:
> Op 29-4-2013 18:41, Carlo Kok schreef:
>> Op 29-4-2013 18:23, Greg Clayton schreef:
>>> 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.
>>
>> Indeed that's my problem. I get several of those with reason "stop" for
>> StepInto. I'm up to date on last weeks trunk update to windows; but I'll
>> try to compile lldb on OSX to see if I can reproduce it there.
>
>
> I get this from the log:
> http://pastebin.com/msnqdi6P
>
> at line 1656 it resumes it, yet still broadcast a "stop", which makes no
> sense to me, nor can I find any way this could happen, I do know it
> doesn't happen if i slowly step through it.

I've narrowed it down to this (line 1622):

ThreadList::ShouldReportStop 3 threads
Thread::ShouldReportStop() tid = 0x1a03: returning vote  for complete 
stack's back plan
...
ThreadList::ShouldReportStop returning yes

ShouldReportStop returns "Yes" because
m_completed_plan_stack.count > 0 in which case it returns:
return m_completed_plan_stack.back()->ShouldReportStop (event_ptr);

Now the last thing in that is a:
Vote
ThreadPlanCallFunction::ShouldReportStop(Event *event_ptr)
{
     if (m_takedown_done || IsPlanComplete())
         return eVoteYes; << goes here.
     else
         return ThreadPlan::ShouldReportStop(event_ptr);
}

Which is the call to g_lookup_implementation_no_stret_function_code.

Does anyone have an idea what else I can check to solve this step into 
issue?

I've not been able to reproduce this on Osx or Linux.