Strange compiler regression in combination with the zap framework

I have pretty much recent Zig Compiler from the master branch installed (0.12.0-dev.1808+69195d0cd) and I did small fixes to compile the zap framework, so the compilation works without an error. However, when I try to run the simplest example, the application fails with SIGILL. This happens before the application can even reach a function inside main. However, I have currently no idea on how to narrow this problem to a simple example down, therefore I am not sure if I should report this problem to the issue tracker.

What fixes?
Also, did you try specifying the target?
You should use the debugger to tell you what the illegal instruction is. See this.

Small fixes like var to const change (as the compiler stops compiling, when not doing this) and fixing build files as the behaviour of AddCSourceFiles changed. My target is x86_64 linux and I didn’t try other targets. The stack trace before the application crashes looks like this:
When it crashes however, there is no seperate stack trace. The application dies immediately and does not print a stack trace. So I don’t know where the illegal instruction exactly it occurs, but here is the assembly from the stack trace.

ud1 is the instruction to purposefully raise an illegal instruction exception. I believe this code is checking for some condition and erroring if it’s not met. I took a look at Zap’s github, and I couldn’t find this function there. All functions in fio.zig are external, so the check is probably being done in one of Zap’s dependencies.

Yeah, the dependency of zap is in a separate repository GitHub - zigzap/ Your high performance web application C framework

I looked at their github page, but couldn’t find the definition for fio_uuid_links_free anywhere. It’s probably hidden underneath many layers of macros. If you can find it, just look at what it’s testing. It’s probably some kind of assertion.

According to my debugger it should be at fio.h:6026 .


Is this occurring only within safe release modes (Debug and ReleaseSafe) or also with ReleaseSmall and ReleaseFast? When C code is involved, illegal instructions could be the result of undefined behavior tripping the undefined behavior sanitizer (ubsan), which is enabled by default in zig cc for safe release modes. Unfortunately, this is currently missing useful information about the source of the undefined behavior detected: Give more info when a UB trap is detected in zig cc debug mode · Issue #5163 · ziglang/zig · GitHub

If adding the option -fno-sanitize=undefined to the C compilation fixes the issue, then that suggests the sanitizer is what’s causing the error here (indicating there is undefined behavior somewhere). Then, if you want to try to get more information about the undefined behavior occurring, Valgrind might be able to give some additional details.

Based on the code snippet and line you shared, perhaps it has something to do with the pointer arithmetic s->ordered + s->pos? The next line indicates that it’s possible for s->ordered to be null, which, as far as I can tell from my limited research, would make any pointer arithmetic on s->ordered undefined behavior.


It happens only in ReleaseSafe and Debug mode. ReleaseFast and ReleaseSmall work without a problem. The option -fno-sanitize=undefined is already activated in the build file of the C dependency. See at 16faf3aba12314c966fc10c99a40d2521177b94b · zigzap/ · GitHub

That’s interesting. I wonder if the option isn’t being applied somehow? Is the code with your modifications available somewhere for others to also debug?

I’ve uploaded it here. Feel free to debug.

1 Like

Oh, and you’re right I didn’t add the flags quite right. Now it works.

1 Like