build-lib -femit-h segfault on linux (Ubuntu 22.04.3 LTS)
Zig Version
0.12.0-dev.1769+bf5ab5451
Steps to Reproduce and Observed Behavior
mkdir zig-example cd zig-example zig init zig build-lib -femit-h src/root.zig -> Segmentation fault (core dumped)
Expected Behavior
not segfault
was able to repro:
thread 14450 panic: reached unreachable code
/home/dr/zig/build/stage3/lib/zig/std/debug.zig:342:14: 0x9107bc in assert (zig)
if (!ok) unreachable; // assertion failure
^
/home/dr/zig/src/Module.zig:4755:19: 0xa69056 in allocateNewDecl (zig)
return mod.intern_pool.destroyNamespace(mod.gpa, index);
^
/home/dr/zig/src/Module.zig:3458:51: 0xcb4be1 in semaFile (zig)
// Decl itself is safely analyzed, and body analysis is not yet queued
^
/home/dr/zig/src/Module.zig:3434:24: 0xcb497f in semaPkg (zig)
.codegen_failure,
^
/home/dr/zig/src/Compilation.zig:3866:27: 0xce7d3d in processOneJob (zig)
module.semaPkg(pkg) catch |err| switch (err) {
^
/home/dr/zig/src/Compilation.zig:3702:30: 0xaba6b8 in performAllTheWork (zig)
try processOneJob(comp, work_item, main_progress_node);
^
/home/dr/zig/src/Compilation.zig:2508:31: 0xab5f12 in update (zig)
try comp.performAllTheWork(main_progress_node);
^
/home/dr/zig/src/main.zig:4283:24: 0xae6112 in updateModule (zig)
try comp.update(main_progress_node);
^
/home/dr/zig/src/main.zig:3684:17: 0xb08cda in buildOutputType (zig)
updateModule(comp) catch |err| switch (err) {
^
/home/dr/zig/src/main.zig:280:31: 0x912ad7 in mainArgs (zig)
return buildOutputType(gpa, arena, args, .{ .build = .Lib });
^
/home/dr/zig/src/main.zig:222:20: 0x90fc85 in main (zig)
return mainArgs(gpa, arena, args);
^
/home/dr/zig/build/stage3/lib/zig/std/start.zig:585:37: 0x90f706 in main (zig)
const result = root.main() catch |err| {
If I download and use Zig 0.11.0, there is no issue. This made me think that there was a regression between master and 0.11.0 but then building 0.11.0 from source also lead to the same issue, which I find odd... (maybe there's an issue on my side with how I'm building from source)
no, building from source means you get zig in debug mode which allows the crash to surface properly
no, building from source means you get zig in debug mode which allows the crash to surface properly
What I meant was that there's no segfault for the 0.11.0 download from https://ziglang.org and the header is emitted as expected, building 0.11.0 from source does exhibit a segfault/crash.
Actually it might just be that in 0.11.0 the crash only happens in debug mode and hence even though there's a bug it doesn't reveal itself in release mode? I'll try build 0.11.0 in release mode from source and see what happens, I guess that will confirm if there's something weird going on with my side of things or not. Thanks.
I have the same behavior on MacOS for a brand new project.
- Zig 0.11.0
- OS: MacOS Sonoma 14.4
- Processor: Apple M2
zig init-lib
zig build-lib -femit-h src/main.zig
Result:
Segmentation fault: 11
same issue at ubuntu 24.04 zig 0.12 and 0.13 zig build-lib src/root.zig -femit-h Segmentation fault (core dumped)
Yep, I have this on zig v0.13.0-dev.344+b2588de6c / Ubuntu 24.04 / x86 as well.
Not just ubuntu, can confirm this happens to me in openSUSE Tumbleweed snapshot 20240524 with zig 0.12.0
Somewhat updated repro with a debug zig build:
~/c/g/z/z/tmp (master)> zig version
0.13.0-dev.351+64ef45eb0
~/c/g/z/z/tmp (master)> zig init
info: created build.zig
info: created build.zig.zon
info: created src/main.zig
info: created src/root.zig
info: see `zig build --help` for a menu of options
~/c/g/z/z/tmp (master)> zig build-lib src/root.zig -femit-h
thread 20843157 panic: reached unreachable code
/Users/steeve/code/github.com/ziglang/zig/lib/std/debug.zig:412:14: 0x10f5065d3 in assert (zig)
if (!ok) unreachable; // assertion failure
^
/Users/steeve/code/github.com/ziglang/zig/src/Module.zig:4783:19: 0x10f9fc187 in allocateNewDecl (zig)
assert(@intFromEnum(decl_index) == mod_emit_h.allocated_emit_h.len);
^
/Users/steeve/code/github.com/ziglang/zig/src/Module.zig:3467:51: 0x10f754feb in semaFile (zig)
const new_decl_index = try mod.allocateNewDecl(new_namespace_index, 0);
^
/Users/steeve/code/github.com/ziglang/zig/src/Module.zig:3314:28: 0x10f754e1f in semaPkg (zig)
return mod.semaFile(file);
^
/Users/steeve/code/github.com/ziglang/zig/src/Compilation.zig:3508:27: 0x10f78cc83 in processOneJob (zig)
module.semaPkg(pkg) catch |err| switch (err) {
^
/Users/steeve/code/github.com/ziglang/zig/src/Compilation.zig:3345:30: 0x10f5eb1cf in performAllTheWork (zig)
try processOneJob(comp, work_item, main_progress_node);
^
/Users/steeve/code/github.com/ziglang/zig/src/Compilation.zig:2132:31: 0x10f5e76e7 in update (zig)
try comp.performAllTheWork(main_progress_node);
^
/Users/steeve/code/github.com/ziglang/zig/src/main.zig:4390:20: 0x10f612c57 in updateModule (zig)
try comp.update(prog_node);
^
/Users/steeve/code/github.com/ziglang/zig/src/main.zig:3416:17: 0x10f672bc7 in buildOutputType (zig)
updateModule(comp, color, root_prog_node) catch |err| switch (err) {
^
/Users/steeve/code/github.com/ziglang/zig/src/main.zig:265:31: 0x10f4ef51b in mainArgs (zig)
return buildOutputType(gpa, arena, args, .{ .build = .Lib }
^
/Users/steeve/code/github.com/ziglang/zig/src/main.zig:209:20: 0x10f4eca17 in main (zig)
return mainArgs(gpa, arena, args);
^
/Users/steeve/code/github.com/ziglang/zig/lib/std/start.zig:524:37: 0x10f4ec65b in main (zig)
const result = root.main() catch |err| {
^
???:?:?: 0x194d3e0df in ??? (???)
???:?:?: 0xb93cffffffffffff in ??? (???)
fish: Job 1, '/Users/steeve/code/github.com/z…' terminated by signal SIGABRT (Abort)
~/c/g/z/z/tmp (master)>
What happens if that assert is removed? I wanted to check myself but got unrelated issues with building due to my environment
What happens if that assert is removed? I wanted to check myself but got unrelated issues with building due to my environment
it seems it "works", but zig actually crashes crashes later on on our project
Using -femit-h generates a new assertion failure now, it looks like this changed a few days ago:
panic: regressed compiler feature: emit-h should hook into updateExports, not decl analysis
It looks like this check was added recently: https://github.com/ziglang/zig/commit/00da182e68
Yes, the panic was added intentionally. Not only was emit-h broken anyway, but the old implementation strategy is fundamentally flawed. This will be resolved at some point, it's just not that high on the priority list right now.
Don't know if it's related but I haven't been able to get any C headers out from zig - there is an example in the 0.13 language docs that doesn't build with 0.13 because no C headers are generated
https://ziggit.dev/t/segmentation-fault-core-dumped-when-using-zig-build-lib-femit-h-on-mathtest-zig-with-zsh/5280
At my linux system, it works. Just add: -lc -femit-h
https://ziggit.dev/t/segmentation-fault-core-dumped-when-using-zig-build-lib-femit-h-on-mathtest-zig-with-zsh/5280
At my linux system, it works. Just add:
-lc -femit-h
Also, the missing: ZIG_TARGET_MAX_INT_ALIGNMENT can add manually.
https://github.com/ziglang/zig/issues/16730
I notice the issue using -ofmt=c, and exits define. So just try it:
- replace
-femit-hwith-ofmt=c, generate the c file; - copy the c file's define to header file;
- the libray can be used finally.