"Internal Error ... Corrupted JSON" logged during builds

Using Swift
1

During command-line builds (swift build) I often see this disturbing message logged, sometimes multiple times:

Internal Error: DecodingError.dataCorrupted: Data was corrupted. Debug description: Corrupted JSON. Underlying error: unexpected end of file

It doesn't seem to cause any problems, but it's definitely not the kind of thing I'd expect to see repeatedly in a production toolchain. I've tried swift package clean but it doesn't make it go away.

I just searched the forum and didn't see any posts about it. Am I somehow the only person who gets this?

[Swift 6.3.2 on macOS, 6.3.0 on Linux]

2 Likes
2

I've definitely seen this before, I've just been ignoring it. I've also been using a build tool (swift-bundler) rather than invoking swift build directly, so I wasn't sure if it was that.

3

Yes, never seen this. It is usually because SwiftPM is constantly querying the Swift compiler for a JSON config about the host/target platform- seemingly too many times if you ask me- and maybe that communication gets garbled sometimes. Try running in very verbose mode with --vv and see if you can catch the failing command and file an issue.

4

+1 for this. And I can reproduced it 100% after I bump my project to use 6.2/6.3. I did not got such log when I was using Swift 6.1 on Linux. So I believe there is some regression here either in swift compiler or swiftpm repo.

I've also been using a build tool (swift-bundler) rather than invoking swift build directly, so I wasn't sure if it was that.

FYI: I'm just using the plain swift build here.

5

I got this extremely frequently in Linux CI for a while. Using regular swift build and swift test . Just checked and our most recent builds don't have it - unsure what changed.

EDIT: Just saw it again but mine looks a little different: Internal Error: DecodingError.dataCorrupted: Data was corrupted. Debug description: Corrupted JSON. Underlying error: unexpected end of file

6

Note: This is an AI-assisted investigation summary and has not been manually confirmed yet. I plan to verify the findings myself and, if they hold up, submit a PR with the fix.

I did some investigation on release/6.3 in a clean Ubuntu aarch64 environment.

I created a small DemoKit set of packages covering:

  • a plain SwiftPM library package
  • a build-tool-plugin package
  • a macro package

The plain package and build-tool-plugin package did not reproduce the issue in my loops. The macro package did reproduce it with the system Swift 6.2.4 toolchain, especially when building with --disable-experimental-prebuilts:

Internal Error: dataCorrupted(Swift.DecodingError.Context(codingPath: [], debugDescription: "Corrupted JSON", underlyingError: Optional(unexpected end of file)))

The failure appears to come from the macro / in-process plugin path, not the SwiftPM PackagePlugin IPC path.

The key finding is that release/6.3 has a teardown path that sends an empty plugin message. That is fine as a stream-level termination signal for a pipe-backed executable plugin, but the in-process plugin server handles each sendMessage call as one complete JSON request and decodes it directly. When it receives the empty message, it tries to decode "" as JSON, which produces the observed EOF / corrupted JSON diagnostic.

The relevant area is:

  • swift/lib/AST/PluginRegistry.cpp
  • swift/include/swift/AST/PluginRegistry.h
  • swift/tools/swift-plugin-server/Sources/SwiftInProcPluginServer/InProcPluginServer.swift

A local fix that worked for me was:

  1. Make the in-process plugin sendMessage path treat an empty message as a no-op, since there is no stream to tear down there.
  2. Remove the teardown-time empty message expectation from the affected macro tests.

After applying that, I built a release/6.3 Linux toolchain and reran the repro matrix:

3 packages x 3 build command variants x 50 iterations = 450 builds

I scanned all logs for:

Internal Error:
Corrupted JSON
unexpected end of file

and the issue did not reproduce anymore.

I also ran the targeted macro lit tests I touched; the relevant tests passed, with one unsupported on this Linux configuration.

So my current hypothesis is that this specific “Corrupted JSON / unexpected end of file” diagnostic is caused by an empty teardown message being routed through the in-process macro plugin JSON decoder. I will follow up after manually confirming the repro and the fix.