From df55f522bd6eb42e81c5723375ac329dc3aa97be Mon Sep 17 00:00:00 2001 From: Pavel Labath Date: Tue, 1 Dec 2015 11:28:47 +0000 Subject: Fix race during process interruption Summary: The following situation was occuring in TestAttachResume: - we did a "continue" from a breakpoint (which involves a private start-stop to step over the breakpoint) - after receiving the stop-reply from the step-over, we issue a "detach" (which requires a process interrupt) - at this moment, the public state is "running", private state is "about-to-be-stopped" (the stopped event was broadcast, but it was not received yet) - StopForDestroyOrDetach (public thread) notes the public state is running, sends an interrupt request to the private thread - private thread gets the eBroadcastBitInterrupt (before the eStateStopped message), and asks the process plugin to stop (via Halt()) - process plugin says it has nothing to do as the process is already stopped - private thread shrugs and carries on. receives the stop event, restores the breakpoint and resumes the process. - after a while, the public thread times out and says it failed to stop the process This patch does the following: - splits Halt() into two functions, private and public, their usage depends on the context - public Halt(): sends eBroadcastBitInterrupt to the private thread and waits for the Stop event - HaltPrivate(): asks the plugin to stop and makes a note that the halt was requested. When the next stop event comes it sets the interrupt flag on it. - removes HijackPrivateProcessEvents(), as the only user (old Halt()) has gone away - removes the m_currently_handling_event hack, as the new Halt() does not need it - adds a use_run_lock parameter to public Halt() and WaitForProcessToStop(). This was needed because RunThreadPlan uses Halt() while holding the run lock and we don't want Halt() to take it away from him. Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D14989 llvm-svn: 254403 --- .../lldbsuite/test/expression_command/timeout/TestCallWithTimeout.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'lldb/packages/Python/lldbsuite/test/expression_command/timeout/TestCallWithTimeout.py') diff --git a/lldb/packages/Python/lldbsuite/test/expression_command/timeout/TestCallWithTimeout.py b/lldb/packages/Python/lldbsuite/test/expression_command/timeout/TestCallWithTimeout.py index 2f16cb49a95..a602afc47ed 100644 --- a/lldb/packages/Python/lldbsuite/test/expression_command/timeout/TestCallWithTimeout.py +++ b/lldb/packages/Python/lldbsuite/test/expression_command/timeout/TestCallWithTimeout.py @@ -57,7 +57,7 @@ class ExprCommandWithTimeoutsTestCase(TestBase): frame = thread.GetFrameAtIndex(0) - value = frame.EvaluateExpression ("wait_a_while (50000)", options) + value = frame.EvaluateExpression ("wait_a_while (200000)", options) self.assertTrue (value.IsValid()) self.assertFalse (value.GetError().Success()) @@ -65,7 +65,7 @@ class ExprCommandWithTimeoutsTestCase(TestBase): interp = self.dbg.GetCommandInterpreter() result = lldb.SBCommandReturnObject() - return_value = interp.HandleCommand ("expr -t 100 -u true -- wait_a_while(50000)", result) + return_value = interp.HandleCommand ("expr -t 100 -u true -- wait_a_while(200000)", result) self.assertTrue (return_value == lldb.eReturnStatusFailed) # Okay, now do it again with long enough time outs: -- cgit v1.2.3