diff options
| author | Jim Ingham <jingham@apple.com> | 2016-05-24 18:29:36 +0000 |
|---|---|---|
| committer | Jim Ingham <jingham@apple.com> | 2016-05-24 18:29:36 +0000 |
| commit | 3cc425837d6a6cfe7efbaa53f493d8b20a9232da (patch) | |
| tree | c2165d6d360995bba1fecf44277c600cd40d92d1 /lldb/source/Target/Process.cpp | |
| parent | 15a2165d645135787874268bc546fb543d6c2d1f (diff) | |
| download | bcm5719-llvm-3cc425837d6a6cfe7efbaa53f493d8b20a9232da.tar.gz bcm5719-llvm-3cc425837d6a6cfe7efbaa53f493d8b20a9232da.zip | |
Lock out Process::RunThreadPlan so only one can be in flight at a time.
What with all sorts of folks (TSAN, ASAN, queue detection, etc...) trying to
gather info by calling functions down in the lower layers of lldb, we've started
to see people running expressions simultaneously. The expression evaluation part
is okay, but only one RunThreadPlan can be active at a time. I added a lock to
enforce that.
<rdar://problem/26431072>
llvm-svn: 270593
Diffstat (limited to 'lldb/source/Target/Process.cpp')
| -rw-r--r-- | lldb/source/Target/Process.cpp | 5 |
1 files changed, 4 insertions, 1 deletions
diff --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp index 85b0abb31aa..d4938094134 100644 --- a/lldb/source/Target/Process.cpp +++ b/lldb/source/Target/Process.cpp @@ -771,6 +771,7 @@ Process::Process(lldb::TargetSP target_sp, ListenerSP listener_sp, const UnixSig m_destroy_in_process(false), m_can_interpret_function_calls(false), m_warnings_issued(), + m_run_thread_plan_lock(), m_can_jit(eCanJITDontKnow) { CheckInWithManager(); @@ -5195,6 +5196,8 @@ Process::RunThreadPlan(ExecutionContext &exe_ctx, lldb::ThreadPlanSP &thread_pla const EvaluateExpressionOptions &options, DiagnosticManager &diagnostic_manager) { ExpressionResults return_value = eExpressionSetupError; + + std::lock_guard<std::mutex> run_thread_plan_locker(m_run_thread_plan_lock); if (!thread_plan_sp) { @@ -5223,7 +5226,7 @@ Process::RunThreadPlan(ExecutionContext &exe_ctx, lldb::ThreadPlanSP &thread_pla // We need to change some of the thread plan attributes for the thread plan runner. This will restore them // when we are done: - + RestorePlanState thread_plan_restorer(thread_plan_sp); // We rely on the thread plan we are running returning "PlanCompleted" if when it successfully completes. |

