[lldb-dev] "step" threading issues

[Carlo Kok]

Op 2-5-2013 18:47, jingham at apple.com schreef:
>
> On May 2, 2013, at 3:41 AM, Carlo Kok <ck at remobjects.com> wrote:
>
>> Op 2-5-2013 12:03, Carlo Kok schreef:
>>> 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.
>>
>> If i change:
>> if (m_completed_plan_stack.size() > 0)
>> to:
>> if (m_completed_plan_stack.size() > 0 && m_plan_stack.size() == 0)
>>
>> in Thread::ShouldReportStop, it works perfectly.
>
> Yes, but that's because then this branch will never get called (m_plan_stack.size() is never 0, there's always a base plan.
>
> So this isn't a correct fix.

I figured it wouldn't be that simple. However it cannot be right that it 
a: resumes the process  and b: returns "yes let the public api know we 
stopped" at the same time.