On Windows CI the swift test process running the sourcekit-lsp suite sometimes dies partway through with a Windows fatal exception instead of reporting test results. There is no Note: Some test targets reported failures line, no failing test, and no captured output for any test — the driver simply stops and build.ps1 reports the raw exit status.
Four occurrences, with three different exception codes:
In each case the [n/m] Testing … progress output stops abruptly at the point shown and the log ends with:
Error: Error: swift exited with code -1073740940.
Invocation:
swift test --scratch-path T:\x86_64-unknown-windows-msvc\SourceKitLSPTests --package-path …\sourcekit-lsp -c release -debug-info-format none --parallel …
at Test-SourceKitLSP, …\swift\utils\build.ps1: line 5363
The truncation point differs every time (35% to 67% through the run) and the tests being scheduled at that moment are unrelated to each other across the four builds — FoldingRangeTests, CodeActionTests, FormattingTests, SwiftCompletionTests. So this does not look tied to any particular test.
Because SwiftPM's parallel runner prints [n/m] Testing … from the driver and only emits captured per-test output for tests that fail, a driver that dies produces no usable diagnostic at all. That makes this the least debuggable of the Windows CI failures.
STATUS_HEAP_CORRUPTION in particular suggests a genuine memory-safety problem rather than a timeout or a scheduling issue, which is what most of the other Windows CI flakiness looks like (#2766). I have no stack trace, so I can't say which component is at fault — it may well belong in swiftlang/swift-package-manager rather than here, and I'm happy to move it if the driver turns out to be the culprit. Filing here because this is where the Windows Test-SourceKitLSP instability is being tracked (#2360, #2766).
Possibly related and possibly a different manifestation of the same underlying problem: in sourcekit-lsp-PR-windows/4267 a single test worker died silently — WorkspaceTestDiscoveryTests.testTargetWithCustomModuleName printed Test Case … started and never reported a result, with no stderr — while the driver survived and reported the target as failed. That is an individual worker crashing rather than the driver, but it has the same "process vanishes with no diagnostic" character.
Logging
Full Jenkins console logs attached, gzipped (raw they are ~28 MB each, over GitHub's attachment limit).
| Attachment |
Exception |
swift-PR-windows-status-1128-heap-corruption.txt.gz |
0xC0000374 |
swift-PR-windows-status-1138-access-violation.txt.gz |
0xC0000005 |
swift-PR-windows-status-1142-illegal-instruction.txt.gz |
0xC000001D |
swift-PR-windows-61249-illegal-instruction.txt.gz |
0xC000001D |
Useful greps:
swift exited with code -10737 # the fatal exception
] Testing SourceKitLSPTests # last scheduled test before the driver died
Some test targets reported failures # absent in all four, unlike ordinary test failures
swift-PR-windows-61249-illegal-instruction.txt.gz
swift-PR-windows-status-1128-heap-corruption.txt.gz
swift-PR-windows-status-1138-access-violation.txt.gz
swift-PR-windows-status-1142-illegal-instruction.txt.gz
On Windows CI the
swift testprocess running the sourcekit-lsp suite sometimes dies partway through with a Windows fatal exception instead of reporting test results. There is noNote: Some test targets reported failuresline, no failing test, and no captured output for any test — the driver simply stops andbuild.ps1reports the raw exit status.Four occurrences, with three different exception codes:
-10737409400xC0000374STATUS_HEAP_CORRUPTION-10737418190xC0000005STATUS_ACCESS_VIOLATION-10737417950xC000001DSTATUS_ILLEGAL_INSTRUCTION-10737417950xC000001DSTATUS_ILLEGAL_INSTRUCTIONIn each case the
[n/m] Testing …progress output stops abruptly at the point shown and the log ends with:The truncation point differs every time (35% to 67% through the run) and the tests being scheduled at that moment are unrelated to each other across the four builds —
FoldingRangeTests,CodeActionTests,FormattingTests,SwiftCompletionTests. So this does not look tied to any particular test.Because SwiftPM's parallel runner prints
[n/m] Testing …from the driver and only emits captured per-test output for tests that fail, a driver that dies produces no usable diagnostic at all. That makes this the least debuggable of the Windows CI failures.STATUS_HEAP_CORRUPTIONin particular suggests a genuine memory-safety problem rather than a timeout or a scheduling issue, which is what most of the other Windows CI flakiness looks like (#2766). I have no stack trace, so I can't say which component is at fault — it may well belong in swiftlang/swift-package-manager rather than here, and I'm happy to move it if the driver turns out to be the culprit. Filing here because this is where the WindowsTest-SourceKitLSPinstability is being tracked (#2360, #2766).Possibly related and possibly a different manifestation of the same underlying problem: in sourcekit-lsp-PR-windows/4267 a single test worker died silently —
WorkspaceTestDiscoveryTests.testTargetWithCustomModuleNameprintedTest Case … startedand never reported a result, with no stderr — while the driver survived and reported the target as failed. That is an individual worker crashing rather than the driver, but it has the same "process vanishes with no diagnostic" character.Logging
Full Jenkins console logs attached, gzipped (raw they are ~28 MB each, over GitHub's attachment limit).
swift-PR-windows-status-1128-heap-corruption.txt.gz0xC0000374swift-PR-windows-status-1138-access-violation.txt.gz0xC0000005swift-PR-windows-status-1142-illegal-instruction.txt.gz0xC000001Dswift-PR-windows-61249-illegal-instruction.txt.gz0xC000001DUseful greps:
swift-PR-windows-61249-illegal-instruction.txt.gz
swift-PR-windows-status-1128-heap-corruption.txt.gz
swift-PR-windows-status-1138-access-violation.txt.gz
swift-PR-windows-status-1142-illegal-instruction.txt.gz