We've seen reports of crashes (none we've been able to reproduce locally) that look like they are caused by concurrent access to a thread plan stack. It looks like there are error paths when an interrupt request to debugserver times out that cause this problem. The thread plan stack access is never in a hot loop, and there aren't enough of them for the extra data member to matter, so there's really no good reason not to protect the access. Adding the mutex revealed a couple of places where we were using "auto" in an iteration when we should have been using "auto &" - we didn't intend to copy the stack - and I fixed those as well.
Details
Details
- Reviewers
JDevlieghere kastiglione
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lldb/include/lldb/Target/ThreadPlanStack.h | ||
---|---|---|
113 | Does this actually have to be a recursive mutex? |
lldb/include/lldb/Target/ThreadPlanStack.h | ||
---|---|---|
113 | For example DiscardAllPlans calls DiscardPlan both of which declare a lock_guard. |
Comment Actions
Yes, I could refactor this to have a no-lock version, but I don't think it's worth complicating things.
clang-tidy: error: 'lldb/Target/Target.h' file not found [clang-diagnostic-error]
not useful