summaryrefslogtreecommitdiff
path: root/lldb/source/Target/ThreadPlanStack.cpp
AgeCommit message (Collapse)Author
2024-11-18Convert ThreadPlanStack's mutex to a shared mutex. (#116438)jimingham
I have some reports of A/B inversion deadlocks between the ThreadPlanStack and the StackFrameList accesses. There's a fair bit of reasonable code in lldb that does "While accessing the ThreadPlanStack, look at that threads's StackFrameList", and also plenty of "While accessing the ThreadPlanStack, look at the StackFrameList." In all the cases I've seen so far, there was at most one of the locks taken that were trying to mutate the list, the other three were just reading. So we could solve the deadlock by converting the two mutexes over to shared mutexes. This patch is the easy part, the ThreadPlanStack mutex. The tricky part was because these were originally recursive mutexes, and recursive access to shared mutexes is undefined behavior according to the C++ standard, I had to add a couple NoLock variants to make sure it didn't get used recursively. Then since the only remaining calls are out to ThreadPlans and ThreadPlans don't have access to their containing ThreadPlanStack, converting this to a non-recursive lock should be safe.
2023-01-04[lldb] Remove unneeded .get() NFCFangrui Song
2022-12-19Revert "[lldb] Remove redundant .c_str() and .get() calls"Muhammad Omair Javaid
This reverts commit fbaf48be0ff6fb24b9aa8fe9c2284fe88a8798dd. This has broken all LLDB buildbots: https://lab.llvm.org/buildbot/#/builders/68/builds/44990 https://lab.llvm.org/buildbot/#/builders/96/builds/33160
2022-12-18[lldb] Remove redundant .c_str() and .get() callsFangrui Song
Removing .c_str() has a semantics difference, but the use scenarios likely do not matter as we don't have NUL in the strings.
2022-04-29Add a mutex to the ThreadPlanStackMap class.Jim Ingham
We've seen very occasional crashes that we can only explain by simultaneous access to the ThreadPlanStackMap, so I'm adding a mutex to protect it. Differential Revision: https://reviews.llvm.org/D124029
2021-12-24Remove redundant return and continue statements (NFC)Kazu Hirata
Identified with readability-redundant-control-flow.
2021-11-11[lldb][NFC] Inclusive Language: rename master plan to controlling planQuinn Pham
[NFC] As part of using inclusive language within the llvm project, this patch renames master plan to controlling plan in lldb. Reviewed By: jingham Differential Revision: https://reviews.llvm.org/D113019
2021-08-01[lldb] Avoid moving ThreadPlanSP from plans vectorDave Lee
Change `ThreadPlanStack::PopPlan` and `::DiscardPlan` to not do the following: 1. Move the last plan, leaving a moved `ThreadPlanSP` in the plans vector 2. Operate on the last plan 3. Pop the last plan off the plans vector This leaves a period of time where the last element in the plans vector has been moved. I am not sure what, if any, guarantees there are when doing this, but it seems like it would/could leave a null `ThreadPlanSP` in the container. There are asserts in place to prevent empty/null `ThreadPlanSP` instances from being pushed on to the stack, and so this could break that invariant during multithreaded access to the thread plan stack. An open question is whether this use of `std::move` was the result of a measure performance problem. Differential Revision: https://reviews.llvm.org/D106171
2021-07-16Add a mutex to guard access to the ThreadPlanStack classJim Ingham
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. Except for preventing crashes this should be NFC. Differential Revision: https\://reviews.llvm.org/D106122
2021-03-04[lldb] Rename QueueFundamentalPlan to QueueBasePlan (NFC)Dave Lee
Minor change for naming consistency. Differential Revision: https://reviews.llvm.org/D97985
2021-02-15[lldb] Remove unused ThreadPlan tracer utilities (NFC)Dave Lee
Delete unused `EnableTracer()` and `SetTracer()` functions on `Thread`. By deleting these, their `ThreadPlan` counterparts also become unused. Then, by deleting `ThreadPlanStack::EnableTracer`, `EnableSingleStep` becomes unused. With no more callers to `EnableSingleStep`, the value `m_single_step` is always true and can be removed as well. Differential Revision: https://reviews.llvm.org/D96666
2021-01-26[lldb] Remove unused ThreadPlanStack::GetStackOfKind (NFC)Dave Lee
This function isn't used. Differential Revision: https://reviews.llvm.org/D95411
2021-01-25[ThreadPlan] fix exec on LinuxWalter Erquinigo
2020-04-15[lldb] Fix -Wparentheses in ThreadPlanStack.cppPavel Labath
2020-04-07Don't access reference to a vector after pop_backBenjamin Kramer
This is undefined behavior. Found by asan's detect_container_overflow.
2020-04-03Fix unused variable, format, and format string warnings.Eric Christopher
NFC.
2020-04-03Allow the ThreadPlanStackMap to hold the thread plans for threadsJim Ingham
that were not reported by the OS plugin. To facilitate this, move adding/updating the ThreadPlans for a Thread to the ThreadPlanStackMap. Also move dumping thread plans there as well. Added some tests for "thread plan list" and "thread plan discard" since I didn't seem to have written any originally. Differential Revision: https://reviews.llvm.org/D76814
2020-04-03Move thread plan stacks into the Process, indexed by TID.Jim Ingham
Differential Revision: https://reviews.llvm.org/D75880
generated by cgit v1.2.3 (git 2.25.1) at 2026-10-23 08:02:23 +0000