New-ish compiler crash when compiling for wasm32-emscripten

Help
1

Posting this here first before creating a ticket in case it rings a bell for somebody (didn’t find obvious similar tickets on codeberg).

Sometime between 24-Mar (last known good version, 0.16.0-dev.2979+e93834410) and 02-Apr (0.16.0-dev.3066+da78940dd) a new bug seems to have slipped in which causes compiling for the wasm32-emscripten target to crash. The compiler crashes with a ‘bus error’ so it’s not one of the “usual” stdlib regressions for wasm32-emscripten.

Only tested on macOS so far - not sure if it affects other platforms, and I didn’t have the time yet to do a proper bisecting.

To reproduce: on an ARM Mac, clone GitHub - floooh/sokol-zig: Zig bindings for the sokol headers (https://github.com/floooh/sokol) · GitHub

In the project repository run the following cmdline (note that you need to fix some of the paths), the command line has been copied from the build system crash output:

zig build-lib -ODebug -target wasm32-emscripten -mcpu baseline --dep sokol -Mroot=[FXME-abs-path]/sokol-zig/examples/sgl.zig -I .zig-cache/o/9e00daaf53b14469111c1b072e37eb52 -Msokol=[FIXME-abs-path]/sokol-zig/src/sokol/sokol.zig -lc --cache-dir .zig-cache --global-cache-dir [FIXME-abs-user-dir]/.cache/zig --name sgl -static --zig-lib-dir [FIXME-abs-zig-toolchain-path]/lib/

…this crashes with

[1]    67181 bus error  zig build-lib -ODebug -target wasm32-emscripten -mcpu baseline --dep sokol  -

…probably easier to diagnose with a Zig toolchain compiled as debug. Besides wasm32-emscripten, another difference to the native build is that the Zig main module is built into a static library instead of an executable (because the actual ‘exe’ is linked via emcc).

Zig version: 0.16.0-dev.3066+da78940dd

PS: the crash also happens at least on Windows, so I guess it’s universal (just with a different error message: error: process exited with error code 5)

PPS: some more info after a bit more testing:

  • the crash doesn’t happen reliably :confused: Just repeating the same command line, sometimes it works, sometimes it doesn’t.
  • wasm32-wasi doesn’t seem to be affected (at least I couldn’t reproduce) - wasm32-freestanding doesn’t compile but that’s expected (the code uses a main function with args)
1 Like
2

I’m still running skinny old Zig, but I just downloaded 0.16.0 (3073 since I couldnt find others) to test this for you on Asahi linux aarch64.
Here it seems to stall for 10s+ at:

[3157/3157] Linking
└─ LLVM Emit Object

and then always crashes with either: Bus error (core dumped) or Segmentation fault (core dumped).
With old Zig I get an artifact: 234612 Apr 4 18:41 libsgl.a.

Not sure if this data point helps, but since you mentioned ARM Mac I thought I’d give it a go.

1 Like
3

Thanks for checking!

I just wrote a ticket:

https://codeberg.org/ziglang/zig/issues/31762

4

Note that 0.16.0 does not exist yet. That is a version that will be tagged in the future. Also, the number of commits (3073) without the commit sha suffix is frustrating because it is easy to get n commits from sha but not the other way around. I have no idea what commit 3073 corresponds to.

Sorry for being pedantic, but I’ve noticed recently people filling out the zig version field on the issue tracker incorrectly which has made it needlessly more difficult to troubleshoot, so I’m trying to correct the misconceptions.

Anyway thanks for the bug report. I’ve made it a release blocker since it is a recent regression.

3 Likes
5

Sorry about that. I’m Fossil based and so wasnt sure which bits were succinct parts of the filename from yesterdays download page. Looks like listed as ‘master’. Does this help:

./zig version
0.16.0-dev.3073+28ae5d415

Let me know if you need more, and happy to try another version if it helps either of you resolve this.