Does anyone else get a compiler segfault when using either zigimg or zigcord? I’ve been trying to upgrade a dither program to 0.16.0 and change the discord library im using for a little bot to avoid a c dependency but both ended up just printing SIGV.
Ensure that you are linking with the C library by using .link_libc = true in your module options.
Yes. For me the compiler crashes when I attempt to use zigimg as a submodule. Both 0.16 and master are crashing. I can avoid this crash by commenting out the line 1446 in src/format/tga.zig which looks like this:
const converted_color = color.Rgb555{
.r = toU5(indexed.palette[data_index].r),
.g = toU5(indexed.palette[data_index].g),
.b = toU5(indexed.palette[data_index].b),
};
You have to comment out the whole loop body and to fake-use a couple of parameters. Code modified like this compiles correctly:
fn writeColorMap16(self: TGA, writer: *std.Io.Writer, indexed: color.IndexedStorage8) Image.WriteError!void {
var data_index: usize = self.header.color_map_spec.first_entry_index;
const data_end: usize = self.header.color_map_spec.first_entry_index + self.header.color_map_spec.length;
while (data_index < data_end) : (data_index += 1) {
// const converted_color = color.Rgb555{
// .r = toU5(indexed.palette[data_index].r),
// .g = toU5(indexed.palette[data_index].g),
// .b = toU5(indexed.palette[data_index].b),
// };
//
// //try writer.writeInt(u16, @as(u15, @bitCast(converted_color)), .little);
// _ = converted_color;
}
_ = writer;
_ = indexed;
}
Interestingly, zigimg on its own compiles correctly and successfully runs its test suite. The crash only happens when i add it as a dependency to my application.
Another peculiarity is that I’m pretty sure the compiler crashed with a SIGSEGV a few days ago. Today it crashed with a SIGABRT when I reproduced the issue.
@dimdin The .link_libc = true in the root module options does not help.
1 Like
I’m so glad I’m not alone on this, I genuinely thought I was doing something wrong, especially after cloning zigimg and all its tests still passed perfectly.
When I tried to find the issue in zigcord it turned out that what was crashing the compiler wasnt even a line of code, but simply using a function. I commented out the entire function and just discarded all values and it still gave me SIGSEGV
Which backend do you use to compile? and which linker?
try exe.use_llvm = true;, exe.use_lld = true;, exe.use_new_linker = false;.
2 Likes
Simply using .use_llvm = true, fixes it, I completely forgot about trying that!
Thank you 
Yes, the .use_llvm = true option helps, either on exe or in the addExecutable options. But why? Without it, Zig seems to crash somewhere in its math library? I mean, I would have never guessed that switching to LLVM could help.
$ zig build
install
└─ install normtobump
└─ compile exe normtobump Debug native failure
error: Compiler crash context:
Generating function 'src.formats.tga.TGA.writeColorMap16'
thread 13015 panic: reached unreachable code
/home/snake/src/zig/lib/std/debug.zig:423:14: 0x1902a79 in assert (std.zig)
if (!ok) unreachable; // assertion failure
^
/home/snake/src/zig/lib/std/math.zig:1124:11: 0x1c3d9f0 in isPowerOfTwo__anon_89937 (std.zig)
assert(int > 0);
^
/home/snake/src/zig/src/codegen/x86_64/CodeGen.zig:174081:34: 0x398f627 in allocRegOrMemAdvanced (main.zig)
if (std.math.isPowerOfTwo(abi_size) and abi_size <= @as(u32, max_abi_size: switch (ty.zigTypeTag(zcu)) {
^
/home/snake/src/zig/src/codegen/x86_64/CodeGen.zig:174066:38: 0x398fdca in allocRegOrMem (main.zig)
return self.allocRegOrMemAdvanced(self.typeOfIndex(inst), inst, reg_ok);
^
/home/snake/src/zig/src/codegen/x86_64/CodeGen.zig:179459:51: 0x4c7f89d in airBitCast (main.zig)
const dst_mcv = try self.allocRegOrMem(inst, true);
^
/home/snake/src/zig/src/codegen/x86_64/CodeGen.zig:67354:42: 0x4cdcc72 in genBody (main.zig)
.bitcast => try cg.airBitCast(inst),
^
/home/snake/src/zig/src/codegen/x86_64/CodeGen.zig:176542:21: 0x4c84aa6 in lowerBlock (main.zig)
try self.genBody(body);
^
/home/snake/src/zig/src/codegen/x86_64/CodeGen.zig:67358:34: 0x4cdce4c in genBody (main.zig)
try cg.lowerBlock(inst, block.body);
^
/home/snake/src/zig/src/codegen/x86_64/CodeGen.zig:176542:21: 0x4c84aa6 in lowerBlock (main.zig)
try self.genBody(body);
^
/home/snake/src/zig/src/codegen/x86_64/CodeGen.zig:67358:34: 0x4cdce4c in genBody (main.zig)
try cg.lowerBlock(inst, block.body);
^
/home/snake/src/zig/src/codegen/x86_64/CodeGen.zig:2289:19: 0x4d9847e in genBodyBlock (main.zig)
try cg.genBody(body);
^
/home/snake/src/zig/src/codegen/x86_64/CodeGen.zig:176435:26: 0x4c9fcba in airCondBr (main.zig)
try self.genBodyBlock(then_body);
^
/home/snake/src/zig/src/codegen/x86_64/CodeGen.zig:89028:41: 0x4ce0f34 in genBody (main.zig)
.cond_br => try cg.airCondBr(inst),
^
/home/snake/src/zig/src/codegen/x86_64/CodeGen.zig:176542:21: 0x4c84aa6 in lowerBlock (main.zig)
try self.genBody(body);
^
/home/snake/src/zig/src/codegen/x86_64/CodeGen.zig:67358:34: 0x4cdce4c in genBody (main.zig)
try cg.lowerBlock(inst, block.body);
^
/home/snake/src/zig/src/codegen/x86_64/CodeGen.zig:2289:19: 0x4d9847e in genBodyBlock (main.zig)
try cg.genBody(body);
^
/home/snake/src/zig/src/codegen/x86_64/CodeGen.zig:67368:36: 0x4cdd1d1 in genBody (main.zig)
try cg.genBodyBlock(block.body);
^
/home/snake/src/zig/src/codegen/x86_64/CodeGen.zig:176542:21: 0x4c84aa6 in lowerBlock (main.zig)
try self.genBody(body);
^
/home/snake/src/zig/src/codegen/x86_64/CodeGen.zig:67358:34: 0x4cdce4c in genBody (main.zig)
try cg.lowerBlock(inst, block.body);
^
/home/snake/src/zig/src/codegen/x86_64/CodeGen.zig:2268:19: 0x4c2d14f in genMainBody (main.zig)
try cg.genBody(main_body[air_arg_count..]);
^
/home/snake/src/zig/src/codegen/x86_64/CodeGen.zig:2064:29: 0x4c11931 in gen (main.zig)
try self.genMainBody(zir, func_zir_inst, comptime_args, air_arg_count);
^
/home/snake/src/zig/src/codegen/x86_64/CodeGen.zig:985:17: 0x4c09f84 in generate (main.zig)
function.gen(&file.zir.?, func_zir.inst, func.comptime_args, call_info.air_arg_count) catch |err| switch (err) {
^
/home/snake/src/zig/src/codegen.zig:163:45: 0x4b12ef2 in generateFunction (main.zig)
const mir = try CodeGen.generate(lf, pt, src_loc, func_index, air, liveness);
^
/home/snake/src/zig/src/Zcu/PerThread.zig:4613:36: 0x4ae2f71 in runCodegenInner (main.zig)
return codegen.generateFunction(lf, pt, zcu.navSrcLoc(nav), func_index, air, &liveness) catch |err| switch (err) {
^
/home/snake/src/zig/src/Zcu/PerThread.zig:4489:43: 0x4adfbe5 in runCodegen (main.zig)
const codegen_result = runCodegenInner(pt, func_index, air);
^
/home/snake/src/zig/src/Zcu.zig:5374:29: 0x4adf7c0 in workerCodegenOwnedAir (main.zig)
return pt.runCodegen(func_index, &air);
^
/home/snake/src/zig/lib/std/Io.zig:2410:13: 0x4adf32f in start (std.zig)
result_casted.* = @call(.auto, function, args_casted.*);
^
/home/snake/src/zig/lib/std/Io/Threaded.zig:741:20: 0x1a7c0fe in start (std.zig)
future.func(future.contextPointer(), future.resultPointer());
^
/home/snake/src/zig/lib/std/Io/Threaded.zig:1797:29: 0x1a77f73 in worker (std.zig)
runnable.startFn(runnable, &thread, t);
^
/home/snake/src/zig/lib/std/Thread.zig:422:13: 0x1a77b25 in callFn__anon_27390 (std.zig)
@call(.auto, f, args);
^
/home/snake/src/zig/lib/std/Thread.zig:755:30: 0x1a77919 in entryFn (std.zig)
return callFn(f, args_ptr.*);
^
???:?:?: 0x7f1dbfe981b8 in ??? (/usr/lib/libc.so.6)
???:?:?: 0x7f1dbff1d21b in ??? (/usr/lib/libc.so.6)
error: process terminated with signal ABRT
failed command: /home/snake/.local/bin/zig build-exe -ODebug --dep zigimg -Mroot=/home/snake/projects/normtobump/src/main.zig -Mzigimg=/home/snake/projects/normtobump/ext/zigimg/zigimg.zig -femit-docs --cache-dir .zig-cache --global-cache-dir /home/snake/.cache/zig --name normtobump --zig-lib-dir /home/snake/.local/lib/zig/ --listen=-
See #31633. color.Rgb555 contains a field of type ToMethods, which is a packed struct(u0).
Since the stacktrace ends is x86_64/CodeGen.zig this is probably a bug in the selfhosted x86_64 codegen (there are compiler failures, where this conclusion is wrong, but I think in this case this is a bug in the selfhosted x86_64 codegen). Because of this, it makes sense, that the llvm codegen is not affected by the bug.
4 Likes
Hi, sorry don’t want to capture the thread, so just tell me if you think I should better open a new one.
However, I’m also getting a segfault error when building my lui app. Thing is, the app runs fine and the segfault only pops up at runtime when I try to end the programm (With q or ctrl.c, as set in my event handler).
More weird, the segfault only occurs when the programm is built with zig build -Doptimize=ReleaseSafe. ReleaseFast and ReleaseSmall work fine.
I found out about that topic because one of my deps, libvaxis, is also using zigimg as dependency. However, I’m not using any image related functions in my programms code.
Since I’m not a pro dev, I’m a little bit lost with the cryptic compiler information (e.g. I have no experience using debugger like GDB). I’m linking libc through my addExecutable() function.
Unfortunately, the solutions suggested here (use_llvm, use_lld…) don’t work for me. And not-working solutions are mentioned as valid reason to reply to an already solved post 
Thus, I’m thankful for every hint. Plus, a great learning opportunity.
Here is the segfault error:
Segmentation fault at address 0x1047526
/home/lukeflo/.cache/zig/p/N-V-__8AAFFSVRWqblwBIcA-Yqv-u7sbjsJoww8K0mWaHbmJ/lib/compiler_rt.zig:684:14: 0x10f0c10 in memset (compiler_rt)
d[0] = c;
^
/home/lukeflo/.cache/zig/p/N-V-__8AAFFSVRWqblwBIcA-Yqv-u7sbjsJoww8K0mWaHbmJ/lib/std/mem/Allocator.zig:448:5: 0x105705b in free__anon_13089 (lui)
@memset(bytes, undefined);
^
../sysdeps/nptl/libc_start_call_main.h:58:16: 0x7f25631c9bfb in __libc_start_call_main (../sysdeps/x86/libc-start.c)
../csu/libc-start.c:360:3: 0x7f25631c9cb4 in __libc_start_main_impl (../sysdeps/x86/libc-start.c)
../sysdeps/x86_64/start.S:115: 0x104fce0 in _start (../sysdeps/x86_64/start.S)
zsh: IOT instruction zig-out/bin/lui -la
I’m on Linux x84_64 with glibc.
You might be hitting this issue https://codeberg.org/ziglang/zig/issues/35373 (the issue title is bit misleading, it affects even non bool types)
Thanks for the hint. However, I was able to fix it through splitting my used allocator into a gpa, used now for long-lasting stuff, and an arena, used now only for fast-changing rendering aspects. Before that change I used an arena for everything.
It solved the segfault, even if I don’t really now why 
The solutions posted here dont wprk for ypu because this is a different issue. My problem was the compiler segfaulting, yours is either your code or a miscompilation.
I would really suggest investing half an hour into gdb. I have been putting this off for wayy to lobg myself and I can only suggest doing it sooner.
Open it with gdb --tui <exe>
Type run
Type bt to get a stacktrace
Typing this on my phone so excuse any small mistakes but I think my instructiond are correct
1 Like
Yes, totally makes sense. I overlooked the “compiler” stated in the title. However, was able to solve it anyway.
Nevertheless, I will have a look into gdb just to get used to. Thanks
Did you test your program (before you changed it) in a debug build and with the DebugAllocator? Chances are that it gives helpful details.
Yeah always. The segfault error only showed up with ReleaseSafe builds. But as mentioned, is fixed now since I refactored the handling of allocators and it solved the problem.