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.
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
