forked from OSchip/llvm-project
Fix TestThreadSpecificBreakpoint.py on Linux after rL252355.
Summary: On Linux, if a thread-specific conditional breakpoint was hit, it won't necessarily be the thread that hit the breakpoint itself that evaluates the conditional expression, so the thread that hit the breakpoint could still be asked to stop, even though it hasn't been allowed to run since the previous stop. Reviewers: sivachandra, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D14472 llvm-svn: 252391
This commit is contained in:
parent
7123e2b5d7
commit
6e8fbc6f39
|
@ -262,7 +262,11 @@ ThreadList::ShouldStop (Event *event_ptr)
|
|||
// This is an optimization... If we didn't let a thread run in between the previous stop and this
|
||||
// one, we shouldn't have to consult it for ShouldStop. So just leave it off the list we are going to
|
||||
// inspect.
|
||||
if (thread_sp->GetTemporaryResumeState () != eStateSuspended)
|
||||
// On Linux, if a thread-specific conditional breakpoint was hit, it won't necessarily be the thread
|
||||
// that hit the breakpoint itself that evaluates the conditional expression, so the thread that hit
|
||||
// the breakpoint could still be asked to stop, even though it hasn't been allowed to run since the
|
||||
// previous stop.
|
||||
if (thread_sp->GetTemporaryResumeState () != eStateSuspended || thread_sp->IsStillAtLastBreakpointHit())
|
||||
threads_copy.push_back(thread_sp);
|
||||
}
|
||||
|
||||
|
|
Loading…
Reference in New Issue