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

[via lldb-commits]

jimingham wrote:



> On Jul 8, 2024, at 12:55 PM, jeffreytan81 ***@***.***> wrote:
> 
> 
> @jimingham <https://github.com/jimingham>, thanks for the comment.
> 
> When I try to add a new testcase for stepping over a function with a user set breakpoint, there is a bug found -- the user set breakpoint did not stop with ThreadPlanSingleThreadTimeout present (which is c case in your RFC comment)
> 
> I did some investigation, when we issue normal step-over, the all thread plans in the stack return false for PlanExplainsStop, so base thread plan got a chance to check thread's stop info and stop the execution.
> 
> However, while doing single thread stepping, ThreadPlanSingleThreadTimeout as leaf plan always return true for PlanExplainsStop, causing the logic to use the second while loop in Thread::ShouldStop(), eventually, ThreadPlanStepOut::MischiefManaged() returns false causing the loop to terminate early without giving base thread plan to decide should stop or not:
> https://github.com/llvm/llvm-project/blob/393eff4e02e7ab3d234d246a8d6912c8e745e6f9/lldb/source/Target/Thread.cpp#L905-L907
> 
> So overall the Thread::ShouldStop() returns false and ignores the hit inner breakpoint during stepping. Any suggestion how to fix this?
> 

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?  What would happen if it just didn't explain this breakpoint, and instead uses marking itself as stale when a user stop like this comes in to make sure it will get popped.

I don't remember anymore why I had to do this as a two-pass thing, making the first plan that explains the stop privileged.  That's an odd asymmetry, and it seems like going back to the "explains stop" loop after processing a previous "I explain the stop" plan will fix this issue.  But it will probably require a bunch of fiddling to get right again (and maybe discovering why I did it this way in the first place)...  So that should be a later resort.

Jim


> —
> Reply to this email directly, view it on GitHub <https://github.com/llvm/llvm-project/pull/90930#issuecomment-2215076062>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADUPVW6W5SM2SXWUGRT3IJLZLLVBZAVCNFSM6AAAAABHEXT7I6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJVGA3TMMBWGI>.
> You are receiving this because you were mentioned.
> 



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