Convert ThreadPlanStack's mutex to a shared mutex. (#116438)

I have some reports of A/B inversion deadlocks between the
ThreadPlanStack and the StackFrameList accesses. There's a fair bit of
reaso

Convert ThreadPlanStack's mutex to a shared mutex. (#116438)

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.

show more ...

[lldb] Remove unneeded .get() NFC

Revert "[lldb] Remove redundant .c_str() and .get() calls"

This reverts commit fbaf48be0ff6fb24b9aa8fe9c2284fe88a8798dd.

This has broken all LLDB buildbots:
https://lab.llvm.org/buildbot/#/builders

Revert "[lldb] Remove redundant .c_str() and .get() calls"

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

show more ...

[lldb] Remove redundant .c_str() and .get() calls

Removing .c_str() has a semantics difference, but the use scenarios
likely do not matter as we don't have NUL in the strings.

Add a mutex to the ThreadPlanStackMap class.
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.

Differ

Add a mutex to the ThreadPlanStackMap class.
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

show more ...

Remove redundant return and continue statements (NFC)

Identified with readability-redundant-control-flow.

[lldb][NFC] Inclusive Language: rename master plan to controlling plan

[NFC] As part of using inclusive language within the llvm project, this patch
renames master plan to controlling plan in lldb.

[lldb][NFC] Inclusive Language: rename master plan to controlling plan

[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

show more ...

[lldb] Avoid moving ThreadPlanSP from plans vector

Change `ThreadPlanStack::PopPlan` and `::DiscardPlan` to not do the following:

1. Move the last plan, leaving a moved `ThreadPlanSP` in the plans

[lldb] Avoid moving ThreadPlanSP from plans vector

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

show more ...

Add a mutex to guard access to the ThreadPlanStack class

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 pla

Add a mutex to guard access to the ThreadPlanStack class

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

show more ...

[lldb] Rename QueueFundamentalPlan to QueueBasePlan (NFC)

Minor change for naming consistency.

Differential Revision: https://reviews.llvm.org/D97985

[lldb] Remove unused ThreadPlan tracer utilities (NFC)

Delete unused `EnableTracer()` and `SetTracer()` functions on `Thread`. By deleting
these, their `ThreadPlan` counterparts also become unused.

[lldb] Remove unused ThreadPlan tracer utilities (NFC)

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

show more ...

[lldb] Remove unused ThreadPlanStack::GetStackOfKind (NFC)

This function isn't used.

Differential Revision: https://reviews.llvm.org/D95411

[ThreadPlan] fix exec on Linux

[lldb] Fix -Wparentheses in ThreadPlanStack.cpp

Don't access reference to a vector after pop_back

This is undefined behavior. Found by asan's detect_container_overflow.

Fix unused variable, format, and format string warnings.
NFC.

Allow the ThreadPlanStackMap to hold the thread plans for threads
that were not reported by the OS plugin. To facilitate this, move
adding/updating the ThreadPlans for a Thread to the ThreadPlanStac

Allow the ThreadPlanStackMap to hold the thread plans for threads
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

show more ...

Move thread plan stacks into the Process, indexed by TID.

Differential Revision: https://reviews.llvm.org/D75880