We've been using the Windows Swift 5.3 and 5.4 snapshots for a while now to compile a cross-platform library. We use the snapshots instead of the official releases because we would rather not maintain a cmake configuration parallel to our SwiftPM configuration, instead using SwiftPM to build everywhere, including Windows.
Since at least November last year, we have been getting an error about 30% of the time when compiling our library:
TSCUtility/Triple.swift:152: Fatal error: could not determine host triple: malformed
This happens most often when building our library using GitHub Actions and their provided Windows 10 environment. However, it also happens when building locally with swift build.
Has anyone else been using the snapshots to gain SwiftPM support on Windows and been having this same stochastic issue?
I've seen this a couple of times, I'd estimate it more like 0.25% or something. I've not been able to reproduce this locally, but my suspicion is that there is something wrong with the deserialization of the payload being processed through a pipe to the child process. If you can actually capture the actual output from the subprocess when building the manifest, that might help identify where things are going wrong.
Less than 1%? That would be nice! We see it most often using GitHub Actions to build and test our library with the snapshot. Because the environment doesn't have swift of any version installed, we install as part of the script. At one point we thought it might have been because the install had not yet completed before compilation had begun, but that might be a red herring.
I'll investigate a bit more. I just didn't see this on the forum yet, which surprised me, since it happens very often in our case.
Definitely looking forward to an official Windows release of Swift with SwiftPM!
No, we haven't! I checked the Platform Support page to see if SwiftPM was reported as supported for Windows and assumed it was not, since that page seems to not have been updated yet.
I will try the official release in our CI/CD system and see if we continue getting the error.
The spurious nature of the bug makes me suspect it is some kind of I/O or timing issue when reading the triple string from the other process. It might be worth adding logging if the triple fails to parse on Windows, so the next time it comes up, we can report which string it's seeing and whether it is garbled or truncated.
(It seems to be happening less often than it used to IMO, but I did just hit it once again a few days ago so it certainly isn't gone)
TSCUtility/Triple.swift:154: Fatal error: could not determine host triple: malformed
I see this error 95% of the time when trying to use sourcekit-lsp.exe, Swift 5.5.2. sourcekit-lsp crashes after initialize request
Wonder why it's not 100%, because this code in Triple.swift (lines 154..158) should always crash on non-Apple platforms:
/// This is currently meant for Apple platforms only.
public func tripleString(forPlatformVersion version: String) -> String {
precondition(isDarwin())
return String(self.tripleString.dropLast(self.osVersion?.count ?? 0)) + version
}
Apple's documentation says that the precondition function will stop program execution (except in -Ounchecked builds).
It would also be great if someone point me in the right direction on how to build from source the TSCUtility.dll compatible with Swift 5.5.2 for Windows. I've tried the swift-tools-support-core, but it does not look compatible. If I could build the compatible dll, I would try to catch the malformed triple.
This snippet runs swiftc --print-target-info to parse the triple, which only serves to reinforce @Karl 's comment about it being an IO or timing issue from the other process.
Wonder why it's not 100%, because this code in Triple.swift (lines 154..158) should always crash on non-Apple platforms
I agree with @3405691582 that you're looking at the wrong source branch and the problem is with parsing the string from the compiler instead, that I pointed out earlier this year.
It would also be great if someone point me in the right direction on how to build from source the TSCUtility.dll compatible with Swift 5.5.2 for Windows.
I've never tried building for Windows but there are directions here, written by @compnerd. You shouldn't need to build the full toolchain with all the prior steps, but if you swap in the appropriate paths to your prebuilt toolchain in those CMake flags, you should be able to build that library alone and swap a modified version of the dll into your toolchain.
You'll have to give us more info on what wasn't "compatible" so far, make sure you check out the right swift-5.5.2-RELEASE tag of that source repo.
Thank you @3405691582 for pointing me to the right branch. @Finagolfin I will take a look at the building directions, thank you too.
You'll have to give us more info on what wasn't "compatible" so far
The swift-tools-support-core builds a single SwiftToolsSupport.dll, while this file is absent in the Swift 5.5.2 toolchain for Windows, which has separate TSCLibc.dll, TSCBasic.dll, and TSCUtility.dll files instead.
I was trying to modify the Package.swift file in the swift-tools-support-core so that it would build the three separate dll files, and successfully built them, but with the newly built files the sourcekit-lsp.exe crashes at start, not being able to find some function entry point in some dll. It was clear that the source branch is wrong, but I did not know where to find the right one.
I still think that precondition(isDarwin()) in public func tripleString requires attention, though not being the source of the error discussed in this thread.
I still think that precondition(isDarwin()) in public func tripleString requires attention, though not being the source of the error discussed in this thread.
That is great! I'm not sure if there was something specific that got fixed or it simply is masked. I know that there was one fix that went in recently that was addressing a race condition in the runloop monitoring, which might also address this. Additionally, @Karl (I think?) make a nice change to swift-tools-support-core that should provide additional diagnostics in case of this failure occurring in the future.
