jimingham wrote: I left some more comments, most of them either nits or future work - unless you want to do them here...
This makes sense to me, so it's likely right. But the tests you've written so far are just about making sure that deadlocks are resolved in a simple stepping situation where nothing user-visible happens while you are stepping. We need to make sure that if the "next" is interrupted - for instance by hitting a breakpoint in the code being stepped over, that once stopped, lldb can do other step operations having stopped and they work as expected. Also, in lldb, if you do a `next` and that steps over a function that hits a breakpoint, the next stays on the stack and then "continue" will resume execution of the "next" ThreadPlan, completing the step. We should make sure that works and keeps tracking the single thread in a case where there's no deadlock to resolve, or goes on to resolve the deadlock. We also really want to make sure that the async interrupt that you use here and the one that the user uses (through SBProcess.SendAsyncInterrupt) don't interfere with one another. So step over something with a really long user step timeout, then send an asynchronous interrupt and make sure we stop with the right stop reason. And then make sure the next continues successfully after that. Also, if we can it would be nice to test that this succeeds in NOT allowing the other threads to run before the timeout elapses. You could have your worker thread stop right before code that's going to crash, and then switch to the main thread and do a bunch of steps over code that calls some function that will do a pthread yield. If the process doesn't crash after those steps, you're good. 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
