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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to