"error: Unexpected" when zig-cache is present, compiles otherwise.

[TeamPuzel]

Zig Version

0.13.0-dev.211+6a65561e3

Steps to Reproduce and Observed Behavior

I'm trying to compile a zig program initially written with zig 0.12, and after fixing some errors where the standard library api changed it still didn't compile, with no other information but error: Unexpected. I deleted the zig-cache and it compiled, however in doing so it created zig-cache again and the issue returned.

To see if it would help I updated my zig to the version above from an earlier 0.13 build, however that did not fix the issue and only got worse.

Expected Behavior

I expected my code to compile regardless of zig-cache being present.

[rohlem]

What platform (OS, arch) does this occur on?
Steps to reproduce would probably also be very helpful in trying to identify the issue.
(Having the full subject code would be ideal.
Sharing this local zig-cache folder and/or the global one may also help, if they exhibit detectable corruption.)

[TeamPuzel]

macOS Sonoma 14.5 Beta (23F5064f) (arm64)

It happens regardless of source code, I deleted everything and just left std.debug.print and nothing changed.

I spammed the run command a bit in frustration and now it's consistently crashing outright 🥲

17:40 bug > zig build run
Hithread 1059942 panic: reached unreachable code
/Users/teampuzel/zig/lib/std/debug.zig:403:14: 0x100a56337 in assert (build)
    if (!ok) unreachable; // assertion failure
             ^
/Users/teampuzel/zig/lib/std/Build/Cache.zig:896:15: 0x100b8ed4f in writeManifest (build)
        assert(self.have_exclusive_lock);
              ^
/Users/teampuzel/zig/lib/std/Build/Step.zig:554:26: 0x100b8f6bf in writeManifest (build)
        man.writeManifest() catch |err| {
                         ^
/Users/teampuzel/zig/lib/std/Build/Step/Run.zig:713:31: 0x100b3371f in make (build)
        try step.writeManifest(&man);
                              ^
/Users/teampuzel/zig/lib/std/Build/Step.zig:182:13: 0x100acd42f in make (build)
    s.makeFn(s, prog_node) catch |err| switch (err) {
            ^
/Users/teampuzel/zig/lib/compiler/build_runner.zig:948:31: 0x100a92c3b in workerMakeOneStep (build)
    const make_result = s.make(&sub_prog_node);
                              ^
/Users/teampuzel/zig/lib/std/Thread/Pool.zig:102:39: 0x100a935a7 in runFn (build)
            @call(.auto, func, closure.arguments);
                                      ^
/Users/teampuzel/zig/lib/std/Thread/Pool.zig:191:18: 0x100af4873 in worker (build)
            runFn(&run_node.data);
                 ^
/Users/teampuzel/zig/lib/std/Thread.zig:408:13: 0x100acbc7b in callFn__anon_14051 (build)
            @call(.auto, f, args);
            ^
/Users/teampuzel/zig/lib/std/Thread.zig:674:30: 0x100a92453 in entryFn (build)
                return callFn(f, args_ptr.*);
                             ^
???:?:?: 0x18f092f93 in ??? (libsystem_pthread.dylib)
???:?:?: 0x480880018f08dd33 in ??? (???)
error: the following build command crashed:
/Users/teampuzel/Documents/Files/Home/Projects/bug/zig-cache/o/0658ecc0d9b5ad930d6409ad7c040e19/build /Users/teampuzel/zig/zig /Users/teampuzel/Documents/Files/Home/Projects/bug /Users/teampuzel/Documents/Files/Home/Projects/bug/zig-cache /Users/teampuzel/.cache/zig --seed 0xdc7693f3 -Za6d0b0b23937661a run

After this I decided to delete the global cache and it went back to this:

17:44 bug > zig build run
error: Unexpected

After also deleting the local cache it turned to this (for a brief moment):

17:44 bug > zig build run
error: failed to rename compilation results ('/Users/teampuzel/Documents/Files/Home/Projects/bug/zig-cache/tmp/7d23d77ee42fb777') into local cache ('/Users/teampuzel/Documents/Files/Home/Projects/bug/zig-cache/o/0658ecc0d9b5ad930d6409ad7c040e19'): Unexpected
17:44 bug > zig build run
error: Unexpected

It's completely unpredictable.
bug.zip

[mikdusan]

are you sync'ing folder(s) to iCloud?

[TeamPuzel]

Yes...
Why would that cause issues, no other programming language I use has a problem with my Projects folder being in Documents

[mikdusan]

zig's caching logic makes extensive use of filesystem features wrt locking, moving/renaming, and it seems sync'd folders behave differently under such pressing conditions. As an aside, I once tried sharing a filesystem from one mac to another, and running zig's cache off that, and it was a disaster mainly due to the impl of filesystem sharing. But that's no surprise, remote filesystems are mostly terrible when it comes to locking and atomic'y operations.

This comment suggests renaming the folder or parent folder to <THING>.nosync #17342 (comment) . I'd say it's worth a try: rename folder, and try to reproduce issue to verify sync'ing as the issue trigger.

[TeamPuzel]

Moved it to a normal folder, deleted both caches, rebooted mac and it still kept crashing, probably for a different reason though

Thankfully I kept the older zig version 0.13.0-dev.46+3648d7df1, reverting to which started compiling again

[pierrec]

zig version
0.13.0-dev.211+6a65561e3

Also getting an error (removing zig-cache/ fixes the issue):

thread 19358740 panic: reached unreachable code
/Users/pierre/sandbox/zig-macos-x86_64-0.13.0-dev.211+6a65561e3/lib/std/debug.zig:403:14: 0x10d20a52c in assert (build)
    if (!ok) unreachable; // assertion failure
             ^
/Users/pierre/sandbox/zig-macos-x86_64-0.13.0-dev.211+6a65561e3/lib/std/Build/Cache.zig:896:15: 0x10d36065b in writeManifest (build)
        assert(self.have_exclusive_lock);
              ^
/Users/pierre/sandbox/zig-macos-x86_64-0.13.0-dev.211+6a65561e3/lib/std/Build/Step.zig:554:26: 0x10d3610fe in writeManifest (build)
        man.writeManifest() catch |err| {
                         ^
/Users/pierre/sandbox/zig-macos-x86_64-0.13.0-dev.211+6a65561e3/lib/std/Build/Step/Run.zig:713:31: 0x10d2fe62e in make (build)
        try step.writeManifest(&man);
                              ^
/Users/pierre/sandbox/zig-macos-x86_64-0.13.0-dev.211+6a65561e3/lib/std/Build/Step.zig:182:13: 0x10d2889a9 in make (build)
    s.makeFn(s, prog_node) catch |err| switch (err) {
            ^
/Users/pierre/sandbox/zig-macos-x86_64-0.13.0-dev.211+6a65561e3/lib/compiler/build_runner.zig:948:31: 0x10d24af9c in workerMakeOneStep (build)
    const make_result = s.make(&sub_prog_node);
                              ^
/Users/pierre/sandbox/zig-macos-x86_64-0.13.0-dev.211+6a65561e3/lib/std/Thread/Pool.zig:102:39: 0x10d24b9f0 in runFn (build)
            @call(.auto, func, closure.arguments);
                                      ^
/Users/pierre/sandbox/zig-macos-x86_64-0.13.0-dev.211+6a65561e3/lib/std/Thread/Pool.zig:191:18: 0x10d2b7791 in worker (build)
            runFn(&run_node.data);
                 ^
/Users/pierre/sandbox/zig-macos-x86_64-0.13.0-dev.211+6a65561e3/lib/std/Thread.zig:408:13: 0x10d2871ea in callFn__anon_14108 (build)
            @call(.auto, f, args);
            ^
/Users/pierre/sandbox/zig-macos-x86_64-0.13.0-dev.211+6a65561e3/lib/std/Thread.zig:674:30: 0x10d24a812 in entryFn (build)
                return callFn(f, args_ptr.*);
                             ^

The build.zig only fails if I enable:

const run = b.addSystemCommand(&.{...});
    run.setCwd(b.path(...));
    run.setEnvironmentVariable(...);
    run.addArgs(&.{
        ...
    });
    b.getInstallStep().dependOn(&run.step);

[rohlem]

@pierrec that looks like it's #19947 , which was fixed in #19956 , merged a couple of hours ago.
The next build on the ziglang download page should have the fix, you can also try applying it in your local copy of std.

[pierrec]

@rohlem thanks a lot, this indeed resolves my issue. Sorry for misidentifying the actual issue.

[rofrol]

@pierrec close?

[pierrec]

@rofrol I did not create this issue, but it looked really really close to mine.
@TeamPuzel WDYT, can you test with a recent zig version?

[theKnightsOfRohan]

I'm also getting the issue @TeamPuzel is experiencing with 0.12.0, macOS Sonoma 14.4.1. Exact same error messages and cause from the cache, either error: Unexpected or error: failed to rename compilation results (...) into local cache (...): Unexpected.

[theKnightsOfRohan]

After some more testing, I've ascertained that the error occurs after some amount of time in between builds, and rm -rf-ing the project-local zig-cache and zig-out does fix the issue.