Description
When I run the test lldb\test\API\tools\lldb-server\TestLldbGdbServer.py on Windows x64 manually it passed (42 tests, skipped=28, expected failures=2).
But when I run ninja -v check-all I got the following error:
======================================================================
FAIL: test_attach_commandline_continue_app_exits_llgs (TestLldbGdbServer.LldbGdbServerTestCase.test_attach_commandline_continue_app_exits_llgs)
----------------------------------------------------------------------
Traceback (most recent call last):
File "D:\llvm-project\lldb\packages\Python\lldbsuite\test\tools\lldb-server\gdbremote_testcase.py", line 48, in test_method
return attrvalue(self)
^^^^^^^^^^^^^^^
File "D:\llvm-project\lldb\test\API\tools\lldb-server\TestLldbGdbServer.py", line 116, in test_attach_commandline_continue_app_exits
self.expect_gdbremote_sequence()
File "D:\llvm-project\lldb\packages\Python\lldbsuite\test\tools\lldb-server\gdbremote_testcase.py", line 652, in expect_gdbremote_sequence
return expect_lldb_gdbserver_replay(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\llvm-project\lldb\packages\Python\lldbsuite\test\tools\lldb-server\lldbgdbserverutils.py", line 181, in expect_lldb_gdbserver_replay
context = sequence_entry.assert_match(asserter, content, context=context)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\llvm-project\lldb\packages\Python\lldbsuite\test\tools\lldb-server\lldbgdbserverutils.py", line 462, in assert_match
self._assert_exact_payload_match(asserter, actual_packet)
File "D:\llvm-project\lldb\packages\Python\lldbsuite\test\tools\lldb-server\lldbgdbserverutils.py", line 422, in _assert_exact_payload_match
assert_packets_equal(asserter, actual_packet, self.exact_payload)
File "D:\llvm-project\lldb\packages\Python\lldbsuite\test\tools\lldb-server\lldbgdbserverutils.py", line 97, in assert_packets_equal
asserter.assertEqual(actual_stripped, expected_stripped)
AssertionError: '$T05thread:9c54;name:a.out;00:000000000000[535 chars]739;' != '$W00'
- $T05thread:9c54;name:a.out;00:0000000000000000;01:40fa2fe27b000000;02:64c407bdf97f0000;03:0000000000000000;04:0100000000000000;05:00b016e27b000000;06:0000000000000000;07:00f52fe27b000000;08:f8f42fe27b000000;09:0000000000000000;0a:0000000000000000;0b:4602000000000000;0c:0000000000000000;0d:00009ecd5a020000;0e:e05d0bbdf97f0000;0f:f84c09bdf97f0000;10:7ac403bdf97f0000;11:4602000000000000;12:3300;13:5300;14:2b00;15:2b00;16:2b00;17:2b00;reason:exception;description:457863657074696f6e203078383030303030303320656e636f756e74657265642061742061646472657373203078376666396264303363343739;
+ $W00
Config=x86_64-D:\build-x64\bin\clang.exe
----------------------------------------------------------------------
python version is 3.12.3
cmake is configured with -DLLVM_LIT_ARGS="-avj 2"
The exception message is Exception 0x80000003 encountered at address 0x7ff9bd03c479.
If exception code 0x80000003 occurs, a hard-coded breakpoint or assertion was hit, but the computer was started with the /NODEBUG switch. This problem should rarely occur. If it occurs repeatedly, make sure that a kernel debugger is connected and that the computer is started with the /DEBUG switch.
This test is flaky on lldb-aarch64-windows buildbot too (note different subtests):
test_first_launch_stop_reply_thread_matches_first_qC_llgs
test_Hg_switches_to_3_threads_launch_llgs