Thread states not properly maintained on Windows

[llvmbot]

Bugzilla Link	24660
Version	unspecified
OS	Windows NT
Blocks	#22140
Reporter	LLVM Bugzilla Contributor

Extended Description

The following tests are failing:

TestThreadStates.ThreadStateTestCase.test_state_after_continue_with_dwarf
TestThreadStates.ThreadStateTestCase.test_state_after_expression_with_dwarf

with the following stack trace:

FAIL

<bound method SBProcess.Kill of <lldb.SBProcess; proxy of <Swig Object of type 'lldb::SBProcess *' at 0x02B74D18> >>: success

Traceback (most recent call last):
File "D:\src\llvm\tools\lldb\test\lldbtest.py", line 551, in wrapper
return func(self, *args, **kwargs)
File "D:\src\llvm\tools\lldb\test\lldbtest.py", line 615, in wrapper
func(*args, **kwargs)
File "D:\src\llvm\tools\lldb\test\functionalities\thread\state\TestThreadStates.py", line 45, in test_state_after_continue_with_dwarf
self.thread_state_after_continue_test()
File "D:\src\llvm\tools\lldb\test\functionalities\thread\state\TestThreadStates.py", line 181, in thread_state_after_continue_test
self.assertFalse(thread.IsStopped(), "Thread state is 'stopped' when it should be running.")
AssertionError: True is not False : Thread state is 'stopped' when it should be running.

[llvmbot]

This sounds awfully similar to something I hit when proving out the llgs work and testing vs. OS X. At the time last year, OS X was not guaranteeing thread state info reliability at the SB level, which I think I had working for Linux, but was then getting diverging results on tests that checked thread state at certain points.

What I'm not remembering is if it really was a OS-related issue or a propagation issue on the lldb infrastructure side. (I seem to think Linux could get it right because we were moving to a thread state coordinator state machine that always knew the state of threads, whereas on OS X I think it was query based and the state wasn't automatically known? Something like that). If we end up having multiple OSes (possibly Windows) that have trouble with that, we might want to rethink how (if?) we expose it, or if we can just fix it, do that.

[llvmbot]

Yea I've seen a lot of tests that are xfailed with comments saying "thread states are not properly maintained". So it sounds like, even if we can get this working on Windows, there's some underlying issue that would be great to fix on the LLDB side. I didn't investigate this long enough to come to a conclusion about what the problem might be on the Windows side, because right now I'm just trying to get down to a clean run of the test suite. I suspect there's at least some improvements we could make on the Windows side, but it's very possible that a more comprehensive fix is needed.