[Lldb-commits] [lldb] New ThreadPlanSingleThreadTimeout to resolve potential deadlock in single thread stepping (PR #90930)

[via lldb-commits]

jimingham wrote:

> > Why does the ThreadPlanSingleThreadTimeout have to claim to explain stops (like a random breakpoint hit) that on the face of it it's not responsible for
> 
> Just a quick comment to add the context for this question: we are doing so to ensure `ThreadPlanSingleThreadTimeout` can stay in the leaf thread plan. And it comes from your suggestion `So ThreadPlanSingleThreadTimeout should always say it explains the stop` in this comment: https://discourse.llvm.org/t/improve-single-thread-stepping/74599/17?u=jeffreytan81

So maybe we need to do something explicit here.  

The ThreadPlanSingleThreadTimeout's desired behavior, IIUC, is either it explains the stop or it should get discarded.  I can't think of any instance where it should stay on the stack when there's a stop that's not for the timeout.  If, for instance, you hit a "next range" breakpoint for a "step over" then we're going to remove the plan and have the thread plan push it again when you resume.

So instead of semi-lying about whether it actually explains stops it knows nothing about, can we add the concept of a plan that "has to be a leaf plan".  So if it doesn't explain a stop during ShouldStop, it will get popped right away.  So after we check "plan explains stop" and get `false` back, we check IsLeafPlan, and if that returns true, pop the plan and go on to the next plan.

The harder option is to either convert the ShouldStop to a single loop that re-enters if the plan that explained the stop returns True to MischiefManaged, or to figure out why the second loop is behaving asymmetrically to the first.  We ought to do the first at some point, but that's probably a lot more work.

https://github.com/llvm/llvm-project/pull/90930