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.
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.
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.