search

llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
27.61k stars 11.35k forks source link

LLDB thread states aren't properly maintained #16196

Open andykaylor opened 11 years ago

andykaylor commented 11 years ago
Bugzilla Link 15824
Version unspecified
OS All
CC @emaste

Extended Description

The state of Thread objects is not properly maintained on Linux. Even when debugging single-threaded inferiors, the thread state does not always properly reflect the actual state of the thread.

labath commented 2 years ago

mentioned in issue llvm/llvm-bugzilla-archive#28455

llvmbot commented 2 years ago

mentioned in issue llvm/llvm-bugzilla-archive#25081

emaste commented 3 years ago

reported fixed on FreeBSD in https://reviews.llvm.org/D90757

labath commented 8 years ago

Bug llvm/llvm-bugzilla-archive#28455 has been marked as a duplicate of this bug.

emaste commented 8 years ago

Another test failing in the same way on FreeBSD now:

====================================================================== FAIL: test_state_after_continue_dwarf (TestThreadStates.ThreadStateTestCase) Test thread state after continue.

Traceback (most recent call last): File "/tank/emaste/src/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2263, in dwarf_test_method return attrvalue(self) File "/tank/emaste/src/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 608, in wrapper func(*args, *kwargs) File "/tank/emaste/src/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 608, in wrapper func(args, **kwargs) File "/tank/emaste/src/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/thread/state/TestThreadStates.py", line 34, in test_state_after_continue self.thread_state_after_continue_test() File "/tank/emaste/src/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/thread/state/TestThreadStates.py", line 141, in thread_state_after_continue_test self.wait_for_running_event() File "/tank/emaste/src/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/thread/state/TestThreadStates.py", line 106, in wait_for_running_event lldbutil.expect_state_changes(self, listener, [lldb.eStateRunning]) File "/tank/emaste/src/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbutil.py", line 750, in expect_state_changes test.assertEqual(expected_state, got_state) AssertionError: 6 != 4 Config=x86_64-/usr/bin/clang

Ran 5 tests in 6.281s

RESULT: FAILED (0 passes, 1 failures, 0 errors, 0 skipped, 4 expected failures, 0 unexpected successes)

[TestThreadStates.py FAILED]

labath commented 8 years ago

Bug llvm/llvm-bugzilla-archive#25081 has been marked as a duplicate of this bug.

emaste commented 10 years ago

With my FreeBSD thread WIP I see the same failure in test_state_after_breakpoint_with_dwarf.

What is odd is that I don't even see SBThread::IsStopped() getting called.

I enabled logging to run the test: export LLDB_LOG="lldb_unit_test.log"
export LLDB_LOG_OPTION="api step process thread event expr state"

and in the log I see: SBDebugger(0x80159b600)::GetSelectedTarget () => SBTarget(0x80b696100): a.out
SBTarget(0x80b696100)::GetProcess () => SBProcess(0x801736000)
SBProcess(0x801736000)::GetNumThreads () => 1
SBProcess(0x801736000)::GetThreadAtIndex (index=0) => SBThread(0x80b701e00)
SBTarget(0x80b696100)::GetProcess () => SBProcess(0x801736000)
SBProcess(0x801736000)::GetTarget () => SBTarget(0x80b696100)
SBTarget(0x80b696100)::GetExecutable () => SBFileSpec(0x80b6abb20)
SBFileSpec(0x80b6abb20)::GetPath (dst_path="/tank/emaste/src/llvm/tools/lldb/test/functionalities/thread/state/a.out", dst_len=1024) => 72 SBProcess(0x801736000)::GetState () => stopped
SBProcess(0x801736000)::GetNumThreads () => 1

I can confirm that the GetThreadAtIndex (index=0) call corresponds to the python test code "thread = process.GetThreadAtIndex(0)"

So I think it may actually be that the SWIG / python interface has some issue rather than the thread's state actually being incorrect.

andykaylor commented 11 years ago

Having written a test for this, I see that the test fails on Darwin platforms as well.