ziglang/zig
261
5.9k
Fork
You've already forked zig
764

Crash when the build system creates options.zig with a atomic file #31960

Open
opened 2026年04月19日 17:18:49 +02:00 by IntegratedQuantum · 8 comments

Zig Version

0.16.0

Steps to Reproduce and Observed Behavior

This happened one of our contributor's computer when compiling Cubyz:

info: Downloading cubyz_deps libraries cubyz_deps_x86_64_linux.
info: Downloading cubyz_test_runner dependency.
thread 691876 panic: programmer bug caused syscall error: INVAL
error return context:
/home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Io/Threaded.zig:4092:31: 0x1297211 in dirAccessPosix (std.zig)
 .NOENT => return error.FileNotFound,
 ^
/home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Io/Dir.zig:439:5: 0x13bff6b in access (std.zig)
 return io.vtable.dirAccess(io.userdata, dir, sub_path, options);
 ^
stack trace:
/home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Io/Threaded.zig:14055:34: 0x124565a in errnoBug (std.zig)
 if (is_debug) std.debug.panic("programmer bug caused syscall error: {t}", .{err});
 ^
/home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Io/Threaded.zig:1440:33: 0x12561b8 in errnoBug (std.zig)
 return Threaded.errnoBug(err);
 ^
/home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Io/Threaded.zig:7613:48: 0x128b3f9 in dirRenamePreserveLinux (std.zig)
 .INVAL => |err| return syscall.errnoBug(err),
 ^
/home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Io/Threaded.zig:7377:59: 0x128a478 in dirRenamePreserve (std.zig)
 if (native_os == .linux) return dirRenamePreserveLinux(old_dir, old_sub_path, new_dir, new_sub_path);
 ^
/home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Io/Dir.zig:1140:39: 0x14b170b in renamePreserve (std.zig)
 return io.vtable.dirRenamePreserve(io.userdata, old_dir, old_sub_path, new_dir, new_sub_path);
 ^
/home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Io/File/Atomic.zig:55:34: 0x14b0e6f in link (std.zig)
 try af.dir.renamePreserve(&tmp_sub_path, af.dir, af.dest_sub_path, io);
 ^
/home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Build/Step/Options.zig:493:29: 0x1a5dd6a in make (std.zig)
 atomic_file.link(io) catch |err| switch (err) {
 ^
/home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Build/Step.zig:278:33: 0x14eb62f in make (std.zig)
 const make_result = s.makeFn(s, options);
 ^
/home/uni/cubyz/master/Cubyz/compiler/zig/lib/compiler/build_runner.zig:1345:26: 0x14e966e in makeStep (build_runner.zig)
 } else if (s.make(.{
 ^
/home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Io.zig:1245:17: 0x14e9295 in start (std.zig)
 _ = @as(Cancelable!void, @call(.auto, function, args_casted.*)) catch {};
 ^
/home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Io/Threaded.zig:552:22: 0x12a99d5 in start (std.zig)
 task.func(task.contextPointer());
 ^
/home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Io/Threaded.zig:1797:29: 0x12a7bd4 in worker (std.zig)
 runnable.startFn(runnable, &thread, t);
 ^
/home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Thread.zig:422:13: 0x12a78b5 in callFn__anon_27824 (std.zig)
 @call(.auto, f, args);
 ^
/home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Thread.zig:1431:30: 0x12a7670 in entryFn (std.zig)
 return callFn(f, self.fn_args);
 ^
/home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/os/linux/x86_64.zig:105:5: 0x12a77d5 in clone (std.zig)
 asm volatile (
 ^

From what we've gathered:

  • It fails while trying to create the options.zig fail from our custom build options as created from b.addOptions
  • the error is EINVAL in renameat2, which is called during the renaming step of the atomic file. In the location we could find a file with a random name and the expected contents that was presumably supposed to be renamed to options.zig for atomic access.
  • the error occurs on Linux Mint Cinnamon 21.3 on both Linux Kernel 5.15 and 6.8
  • the error does not occur on my own computer which uses Linux Mint MATE 21.2 + Kernel 6.8
  • the error is repeatable, and happens every time

We managed to find a workaround, by manually renaming the file in question to options.zig in the cache, then it would not try to do the atomic renaming anymore.

Expected Behavior

The options step should not fail on ordinary systems.

### Zig Version 0.16.0 ### Steps to Reproduce and Observed Behavior This happened one of our contributor's computer when compiling Cubyz: ``` info: Downloading cubyz_deps libraries cubyz_deps_x86_64_linux. info: Downloading cubyz_test_runner dependency. thread 691876 panic: programmer bug caused syscall error: INVAL error return context: /home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Io/Threaded.zig:4092:31: 0x1297211 in dirAccessPosix (std.zig) .NOENT => return error.FileNotFound, ^ /home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Io/Dir.zig:439:5: 0x13bff6b in access (std.zig) return io.vtable.dirAccess(io.userdata, dir, sub_path, options); ^ stack trace: /home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Io/Threaded.zig:14055:34: 0x124565a in errnoBug (std.zig) if (is_debug) std.debug.panic("programmer bug caused syscall error: {t}", .{err}); ^ /home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Io/Threaded.zig:1440:33: 0x12561b8 in errnoBug (std.zig) return Threaded.errnoBug(err); ^ /home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Io/Threaded.zig:7613:48: 0x128b3f9 in dirRenamePreserveLinux (std.zig) .INVAL => |err| return syscall.errnoBug(err), ^ /home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Io/Threaded.zig:7377:59: 0x128a478 in dirRenamePreserve (std.zig) if (native_os == .linux) return dirRenamePreserveLinux(old_dir, old_sub_path, new_dir, new_sub_path); ^ /home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Io/Dir.zig:1140:39: 0x14b170b in renamePreserve (std.zig) return io.vtable.dirRenamePreserve(io.userdata, old_dir, old_sub_path, new_dir, new_sub_path); ^ /home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Io/File/Atomic.zig:55:34: 0x14b0e6f in link (std.zig) try af.dir.renamePreserve(&tmp_sub_path, af.dir, af.dest_sub_path, io); ^ /home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Build/Step/Options.zig:493:29: 0x1a5dd6a in make (std.zig) atomic_file.link(io) catch |err| switch (err) { ^ /home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Build/Step.zig:278:33: 0x14eb62f in make (std.zig) const make_result = s.makeFn(s, options); ^ /home/uni/cubyz/master/Cubyz/compiler/zig/lib/compiler/build_runner.zig:1345:26: 0x14e966e in makeStep (build_runner.zig) } else if (s.make(.{ ^ /home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Io.zig:1245:17: 0x14e9295 in start (std.zig) _ = @as(Cancelable!void, @call(.auto, function, args_casted.*)) catch {}; ^ /home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Io/Threaded.zig:552:22: 0x12a99d5 in start (std.zig) task.func(task.contextPointer()); ^ /home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Io/Threaded.zig:1797:29: 0x12a7bd4 in worker (std.zig) runnable.startFn(runnable, &thread, t); ^ /home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Thread.zig:422:13: 0x12a78b5 in callFn__anon_27824 (std.zig) @call(.auto, f, args); ^ /home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/Thread.zig:1431:30: 0x12a7670 in entryFn (std.zig) return callFn(f, self.fn_args); ^ /home/uni/cubyz/master/Cubyz/compiler/zig/lib/std/os/linux/x86_64.zig:105:5: 0x12a77d5 in clone (std.zig) asm volatile ( ^ ``` From what we've gathered: - It fails while trying to create the `options.zig` fail from our custom build options as created from `b.addOptions` - the error is `EINVAL` in `renameat2`, which is called during the renaming step of the atomic file. In the location we could find a file with a random name and the expected contents that was presumably supposed to be renamed to `options.zig` for atomic access. - the error occurs on Linux Mint Cinnamon 21.3 on both Linux Kernel 5.15 and 6.8 - the error does not occur on my own computer which uses Linux Mint MATE 21.2 + Kernel 6.8 - the error is repeatable, and happens every time --- We managed to find a workaround, by manually renaming the file in question to `options.zig` in the cache, then it would not try to do the atomic renaming anymore. ### Expected Behavior The options step should not fail on ordinary systems.

I had the same issue when trying to build ZLS. I use Linux Mint Cinnamon 22.3, kernel 6.17.0-20, Zig 0.16.0

I had the same issue when trying to build ZLS. I use Linux Mint Cinnamon 22.3, kernel 6.17.0-20, Zig 0.16.0
Contributor
Copy link

Duplicate of #31542

Zig's CI doesn't cover less common filesystems that don't support certain syscall flags such as TMPFILE and NOREPLACE and so fails on several test cases including for atomic file creation.

I've also encountered this on ecryptfs, which apparently linux mint still uses despite it being unmaintained? That might explain your failures if you are running zig on an encrypted filesystem.

Last time I checked 2 months ago, EINVAL is very overloaded in renameat2, it could mean the some flag is not supported (why not use OPNOTSUPP then?), or 4 other causes. So it's not trivial to fix this specific bug while retaining atomic behavior.

Duplicate of https://codeberg.org/ziglang/zig/issues/31542 Zig's CI doesn't cover less common filesystems that don't support certain syscall flags such as TMPFILE and NOREPLACE and so fails on several test cases including for atomic file creation. I've also encountered this on ecryptfs, which apparently linux mint still uses despite it being unmaintained? That might explain your failures if you are running zig on an encrypted filesystem. Last time I checked 2 months ago, EINVAL is very overloaded in `renameat2`, it could mean the some flag is not supported (why not use OPNOTSUPP then?), or 4 other causes. So it's not trivial to fix this specific bug while retaining atomic behavior.
Author
Contributor
Copy link

I can confirm that the filesystem is different, the contributor in question has zfs, while I have ext4

I can confirm that the filesystem is different, the contributor in question has zfs, while I have ext4

I think I have gotten the similar issue since my laptop is dual booted and the setting is the following:

My laptop is legion 7i gen 10, containing 2 SSD slots which I use one of them as a "D" drive, sharing data for both of my Linux and Windows, and I have to admit that I didn't do a good job on the partition which my partition have the following formats:

Disk 1:
Windows partition: NTFS.
Ubuntu: Ext4,

Disk 2:
Shared drive for both OS: NTFS

When I was running the project in Disk 2, the same error occurred:

thread 12645 panic: programmer bug caused syscall error: INVAL
error return context:
/home/logickin/.zvm/0.16.0/lib/std/Io/Threaded.zig:4092:31: 0x121fac1 in dirAccessPosix (std.zig)
 .NOENT => return error.FileNotFound,
 ^
/home/logickin/.zvm/0.16.0/lib/std/Io/Dir.zig:439:5: 0x134e82b in access (std.zig)
 return io.vtable.dirAccess(io.userdata, dir, sub_path, options);
 ^
stack trace:

I don't post the remaining stack trace since I got the identical stack trace as @IntegratedQuantum, starting from Threaded.zig. Because of this issue, I decided to clone my repo into my local Ubuntu partition, and it works without issue given the same code.

This problem didn't happen in older version of zig but 0.16.0 since I have been working on this library since 0.15.2 and I have been toggling between OS to test the library that I didn't have any issue until the recent zig update, and this only happens for Linux.

I think I have gotten the similar issue since my laptop is dual booted and the setting is the following: My laptop is legion 7i gen 10, containing 2 SSD slots which I use one of them as a "D" drive, sharing data for both of my Linux and Windows, and I have to admit that I didn't do a good job on the partition which my partition have the following formats: Disk 1: Windows partition: NTFS. Ubuntu: Ext4, Disk 2: Shared drive for both OS: NTFS When I was running the project in Disk 2, the same error occurred: ``` thread 12645 panic: programmer bug caused syscall error: INVAL error return context: /home/logickin/.zvm/0.16.0/lib/std/Io/Threaded.zig:4092:31: 0x121fac1 in dirAccessPosix (std.zig) .NOENT => return error.FileNotFound, ^ /home/logickin/.zvm/0.16.0/lib/std/Io/Dir.zig:439:5: 0x134e82b in access (std.zig) return io.vtable.dirAccess(io.userdata, dir, sub_path, options); ^ stack trace: ``` I don't post the remaining stack trace since I got the identical stack trace as @IntegratedQuantum, starting from Threaded.zig. Because of this issue, I decided to clone my repo into my local Ubuntu partition, and it works without issue given the same code. This problem didn't happen in older version of zig but 0.16.0 since I have been working on this library since 0.15.2 and I have been toggling between OS to test the library that I didn't have any issue until the recent zig update, and this only happens for Linux.
Contributor
Copy link

I've updated #31542's title so it includes all "less common" filesystems, i.e. not covered by CI.

I think it would be more useful if people execute std unit tests on their filesystems and share the unique failures in one place so the core team knows what to expect from each filesystem.

Zig's unit tests already reproduce the bug reported here, but there are more bugs.

I've updated https://codeberg.org/ziglang/zig/issues/31542's title so it includes all "less common" filesystems, i.e. not covered by CI. I think it would be more useful if people execute std unit tests on their filesystems and share the unique failures in one place so the core team knows what to expect from each filesystem. Zig's unit tests already reproduce the bug reported here, but there are more bugs.

@eshom wrote in #31960 (comment):

I think it would be more useful if people execute std unit tests on their filesystems and share the unique failures in one place so the core team knows what to expect from each filesystem.

Thanks for your info, this is actually something I just know today, so I will do the test in some point of time to see if I have something new, and I will follow that thread to see the progress to the bug.

@eshom wrote in https://codeberg.org/ziglang/zig/issues/31960#issuecomment-15402686: > I think it would be more useful if people execute std unit tests on their filesystems and share the unique failures in one place so the core team knows what to expect from each filesystem. Thanks for your info, this is actually something I just know today, so I will do the test in some point of time to see if I have something new, and I will follow that thread to see the progress to the bug.

Renaming most files under .zig-cache/c/**/ solved this for me, but finding the right files to rename was basically just a lucky guess. Any way to pinpoint them reliably?

Renaming most files under `.zig-cache/c/**/` solved this for me, but finding the right files to rename was basically just a lucky guess. Any way to pinpoint them reliably?
Author
Contributor
Copy link

If you need to do this repeatedly, you can put a debug print in one of the functions in the stack trace so it prints the name of the file it's trying to rename.

If you need to do this repeatedly, you can put a debug print in one of the functions in the stack trace so it prints the name of the file it's trying to rename.
Sign in to join this conversation.
No Branch/Tag specified
master
elfv2
spork8
restricted
0.16.x
panic-rewrite
parking-futex-lockfree
windows-Io-cleanup
Io-watch
ParseCommandLineOptions
windows-async-files
poll-ring
debug-file-leaks-differently
debug-file-leaks
ProcessPrng
elfv2-dyn
jobserver
threadtheft
io-threaded-no-queue
0.15.x
Io.net
comptime-allocator
restricted-function-pointers
cli
wasm-linker-writer
wrangle-writer-buffering
sha1-stream
async-await-demo
fixes
0.14.x
ast-node-methods
macos-debug-info
make-vs-configure
fuzz-macos
sans-aro
ArrayList-reserve
incr-bug
llvm-ir-nosanitize-metadata
ci-tarballs
ci-scripts
threadpool
0.12.x
new-pkg-hash
json-diagnostics
more-doctests
rework-comptime-mutation
0.11.x
ci-perf-comment
stage2-async
0.10.x
autofix
0.9.x
aro
hcs
0.8.x
0.7.x
0.16.0
0.15.2
0.15.1
0.15.0
0.14.1
0.14.0
0.12.1
0.13.0
0.12.0
0.11.0
0.10.1
0.10.0
0.9.1
0.9.0
0.8.1
0.8.0
0.7.1
0.7.0
0.6.0
0.5.0
0.4.0
0.3.0
0.2.0
0.1.1
0.1.0
Labels
Clear labels
abi/f32
abi/ilp32
abi/sf
accepted
This proposal is planned.
arch/21k
arch/6502
arch/aarch64
arch/alpha
arch/amdgcn
arch/arc
arch/arc32
arch/arc64
arch/arm
arch/avr
arch/bfin
arch/bpf
arch/colossus
arch/cris
arch/csky
arch/dlx
arch/epiphany
arch/fr30
arch/frv
arch/hexagon
arch/hppa
arch/hppa64
arch/ia64
arch/kalimba
arch/kvx
arch/lanai
arch/lm32
arch/loongarch32
arch/loongarch64
arch/m32r
arch/m68k
arch/m88k
arch/mcore
arch/microblaze
arch/mips
arch/mips64
arch/mmix
arch/moxie
arch/mrisc32
arch/msp430
arch/nds32
arch/ns32k
arch/nvptx
arch/or1k
arch/powerpc
arch/powerpc64
arch/propeller
arch/riscv32
arch/riscv64
arch/rl78
arch/rx
arch/s390x
arch/sh
arch/sparc
arch/sparc64
arch/spirv
arch/spu
arch/tricore
arch/v850
arch/vax
arch/vc4
arch/ve
arch/wasm
arch/x86
arch/x86_64
arch/xcore
arch/xtensa
autodoc
The web application for interactive documentation and generation of its assets.
backend/c
The C backend outputs C source code.
backend/llvm
The LLVM backend outputs an LLVM bitcode module.
backend/self-hosted
The self-hosted backends produce machine code directly.
binutils
Zig's included binary utilities: zig ar, zig dlltool, zig lib, zig ranlib, zig objcopy, and zig rc.
breaking
Implementing this issue could cause existing code to no longer compile or have different behavior.
build system
The Zig build system - zig build, std.Build, the build runner, and package management.
debug info
An issue related to debug information (e.g. DWARF) produced by the Zig compiler.
docs
An issue with documentation, e.g. the language reference or standard library doc comments.
error message
This issue points out an error message that is unhelpful and should be improved.
frontend
Tokenization, parsing, AstGen, ZonGen, Sema, Legalize, and Liveness.
fuzzing
An issue related to Zig's integrated fuzz testing.
incremental
Reuse of internal compiler state for faster compilation.
lib/c
This issue relates to Zig's libc implementation and/or vendored libcs.
lib/compiler-rt
This issue relates to Zig's compiler-rt library.
lib/cxx
This issue relates to Zig's vendored libc++ and/or libc++abi.
lib/std
This issue relates to Zig's standard library.
lib/tsan
This issue relates to Zig's vendored libtsan.
lib/ubsan-rt
This issue relates to Zig's ubsan-rt library.
lib/unwind
This issue relates to Zig's vendored libunwind.
linking
Zig's integrated object file and incremental linker.
miscompilation
The compiler reports success but produces semantically incorrect code.
os/android
os/contiki
os/dragonfly
os/driverkit
os/emscripten
os/freebsd
os/fuchsia
os/haiku
os/hermit
os/hurd
os/illumos
os/ios
os/linux
os/maccatalyst
os/macos
os/managarm
os/netbsd
os/ohos
os/openbsd
os/plan9
os/redox
os/rtems
os/serenity
os/tvos
os/uefi
os/visionos
os/wasi
os/watchos
os/windows
proposal
This issue suggests language modifications. If it also has the "accepted" label then it is planned.
release notes
This issue or pull request should be mentioned in the release notes.
testing
This issue is related to testing the compiler, standard library, or other parts of Zig.
zig cc
Zig as a drop-in C-family compiler.
zig fmt
The Zig source code formatter.
zig reduce
The Zig source code reduction tool.
bounty
https://ziglang.org/news/announcing-donor-bounties
bug
Observed behavior contradicts documented or intended behavior.
contributor-friendly
This issue is limited in scope and/or knowledge of project internals.
downstream
An issue with a third-party project that uses this project.
enhancement
Solving this issue will likely involve adding new logic or components to the codebase.
infra
An issue related to project infrastructure, e.g. continuous integration.
optimization
A task to improve performance and/or resource usage.
question
No questions on the issue tracker; use a community space instead.
regression
Something that used to work in a previous version stopped working
upstream
An issue with a third-party project that this project uses.
use case
Describes a real use case that is difficult or impossible, but does not propose a solution.
No labels
abi/f32
abi/ilp32
abi/sf
accepted
arch/21k
arch/6502
arch/aarch64
arch/alpha
arch/amdgcn
arch/arc
arch/arc32
arch/arc64
arch/arm
arch/avr
arch/bfin
arch/bpf
arch/colossus
arch/cris
arch/csky
arch/dlx
arch/epiphany
arch/fr30
arch/frv
arch/hexagon
arch/hppa
arch/hppa64
arch/ia64
arch/kalimba
arch/kvx
arch/lanai
arch/lm32
arch/loongarch32
arch/loongarch64
arch/m32r
arch/m68k
arch/m88k
arch/mcore
arch/microblaze
arch/mips
arch/mips64
arch/mmix
arch/moxie
arch/mrisc32
arch/msp430
arch/nds32
arch/ns32k
arch/nvptx
arch/or1k
arch/powerpc
arch/powerpc64
arch/propeller
arch/riscv32
arch/riscv64
arch/rl78
arch/rx
arch/s390x
arch/sh
arch/sparc
arch/sparc64
arch/spirv
arch/spu
arch/tricore
arch/v850
arch/vax
arch/vc4
arch/ve
arch/wasm
arch/x86
arch/x86_64
arch/xcore
arch/xtensa
autodoc
backend/c
backend/llvm
backend/self-hosted
binutils
breaking
build system
debug info
docs
error message
frontend
fuzzing
incremental
lib/c
lib/compiler-rt
lib/cxx
lib/std
lib/tsan
lib/ubsan-rt
lib/unwind
linking
miscompilation
os/android
os/contiki
os/dragonfly
os/driverkit
os/emscripten
os/freebsd
os/fuchsia
os/haiku
os/hermit
os/hurd
os/illumos
os/ios
os/linux
os/maccatalyst
os/macos
os/managarm
os/netbsd
os/ohos
os/openbsd
os/plan9
os/redox
os/rtems
os/serenity
os/tvos
os/uefi
os/visionos
os/wasi
os/watchos
os/windows
proposal
release notes
testing
zig cc
zig fmt
zig reduce
bounty
bug
contributor-friendly
downstream
enhancement
infra
optimization
question
regression
upstream
use case
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
5 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ziglang/zig#31960
Reference in a new issue
ziglang/zig
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?