I don't see this happening on Mac OS X. That test succeeds, and I don't see
the behavior you describe.
You should not need to clear the completed plan stack. The way it is supposed
to work is as follows:
Running functions is always done by Process::RunThreadPlan. After the
ThreadPlanCallFunction gets done running in that function, we do this
bit of code:
// Restore the thread state if we are going to discard the plan
execution.
if (return_value == eExecutionCompleted || discard_on_error)
{
thread_plan_sp->RestoreThreadState();
}
That should set the StopInfo that was squirreled away in
Thread::CheckpointThreadState back as the current StopInfo for the thread. Is
that getting called? If not, why not? If it is getting called, why isn't it
succeeding in resetting the thread's StopInfo back to the old reason?
Note, up till a couple of weeks ago this work was done in the DoTakedown method
of ThreadPlanCallFunction, but I moved resetting the StopInfo out of that
function (which gets called while the stop event for the function call is still
being processed) to here, because otherwise it might trigger the original
StopInfo's PerformAction while you are in the middle of handing the
ThreadPlanCallFunction's execution, which isn't right.
Hope that helps.
Jim
On Dec 5, 2012, at 3:28 PM, "Kaylor, Andrew" <[email protected]> wrote:
> Hi all,
>
> I’ve been debugging a problem on Linux where if you hit a breakpoint, then
> evaluate an expression that requires JITing, then continue LLDB will break at
> the line you were already on. I don’t know if this problem is specific to
> Linux, but that’s where I’m debugging it. This problem appears in the
> ‘lang/c/setvalues/TestSetValues.py’ test case, but can also be reproduced
> manually.
>
> What I’m seeing is that when the ‘continue’ handling calls
> Thread::SetupForResume() the current Thread reports its stop reason as
> ‘eStopReasonPlanComplete’ because the ThreadPlan for evaluating the
> expression is still on the completed plans stack. As a result, the
> ThreadPlanStepOverBreakpoint plan doesn’t get queued. If I add calls to
> ‘m_completed_plan_stack.clear()’ and ‘m_discarded_plan_stack.clear()’ at the
> top of the ‘if (GetResumeState() == eStateSuspended)’ block in
> Thread::SetupForResume() then everything works as expected.
>
> Obviously, that feels like a pretty risky thing to do, at best. It seems
> like the expression command handling should have done something to clear the
> completed plan stack when it was finished, but as of yet I haven’t found a
> place where that is appropriate.
>
> Can anyone give me guidance on this issue?
>
> Thanks,
> Andy
> _______________________________________________
> lldb-dev mailing list
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
