Summary
Occasionally, during a normal play session (never at game startup), the client crashes with a stack trace like:
java.lang.RuntimeException: Failed to load class file for '<some class>'!
at net.fabricmc.loader.impl.launch.knot.KnotClassDelegate.getRawClassByteArray(...)
Caused by: java.util.zip.ZipException: ZipFile invalid LOC header (bad signature)
The specific class named in the error is different every time and isn't consistently the same one, which points to a race condition rather than a corrupted file.
What this is
This is an acknowledged upstream Fabric Loader thread-safety issue - java.util.zip.ZipFile isn't safe for fully concurrent reads, and if two threads happen to trigger a lazy class-load from the same mod jar at the same moment, one read can corrupt the other's. It's not specific to this mod; any large Fabric mod jar can hit it, and it gets more likely the longer/more active a session is (more of Minecraft's own background threads - resource loading, sound loading, chunk building - running concurrently).
What we've ruled out
- On-disk jar corruption (checksums and
unzip -t integrity checks always pass immediately after a crash)
- A stale/incremental build artifact (a full clean rebuild reproduces a byte-identical jar)
- File descriptor exhaustion, a sync/backup tool touching the mods folder, filesystem issues
- An old Fabric Loader version (reproduced on 0.19.5, the latest stable at time of writing)
- Hardware/memory errors (checked kernel logs and memory availability around crash timestamps - nothing)
Workaround
There isn't a code-level fix available from this project - it lives in Fabric Loader's own class loader. If you hit this, just relaunch. Worth revisiting only if the crash starts reproducing on the same class reliably, or starts happening at boot instead of mid-session - either would point to something else going on.
Summary
Occasionally, during a normal play session (never at game startup), the client crashes with a stack trace like:
The specific class named in the error is different every time and isn't consistently the same one, which points to a race condition rather than a corrupted file.
What this is
This is an acknowledged upstream Fabric Loader thread-safety issue -
java.util.zip.ZipFileisn't safe for fully concurrent reads, and if two threads happen to trigger a lazy class-load from the same mod jar at the same moment, one read can corrupt the other's. It's not specific to this mod; any large Fabric mod jar can hit it, and it gets more likely the longer/more active a session is (more of Minecraft's own background threads - resource loading, sound loading, chunk building - running concurrently).What we've ruled out
unzip -tintegrity checks always pass immediately after a crash)Workaround
There isn't a code-level fix available from this project - it lives in Fabric Loader's own class loader. If you hit this, just relaunch. Worth revisiting only if the crash starts reproducing on the same class reliably, or starts happening at boot instead of mid-session - either would point to something else going on.