wasm-opt crashes with segmentation fault on big project

[gggrafff]

Hello! We found that wasm-opt sometimes crashes with the error `Segmentation fault (core dumped)'.

What can help with debugging:

• We use wasm-opt together with tinygo.
• The error appears on a large project, if we remove any parts from this project in order to reduce the project, the error disappears. We couldn't make a minimal example to reproduce, and our project is proprietary and I can't give it.
• The error is not reproducible on mac, valid working configuration:

% tinygo version
tinygo version 0.37.0 darwin/amd64 (using go version go1.22.12 and LLVM version 19.1.2)
% /usr/local/bin/wasm-opt --version
wasm-opt version 117

• The error is consistently reproduced on linux on different hardware, with different operating systems, different versions of wasm-opt (tested 116 and 123).
• The error is reproduced only on your builds (https://github.com/WebAssembly/binaryen/releases). When I downloaded the project and built it myself, the error did not reproduce.

Own build, does not fall:

$ rm /tmp/tinygo3733807473/main.wasmopt
$ ls /tmp/tinygo3733807473/
main  main.o
$ ./build/bin/wasm-opt --version
wasm-opt version 123 (version_123)
$ ./build/bin/wasm-opt -O2 -g /tmp/tinygo3733807473/main --output /tmp/tinygo3733807473/main.wasmopt
$ ls /tmp/tinygo3733807473/
main  main.o  main.wasmopt

Downloaded build of the same version crashes:

$ rm /tmp/tinygo3733807473/main.wasmopt
$ ls /tmp/tinygo3733807473/
main  main.o
$ /opt/binaryen-version_123/bin/wasm-opt --version
wasm-opt version 123 (version_123)
$ /opt/binaryen-version_123/bin/wasm-opt -O2 -g /tmp/tinygo3733807473/main --output /tmp/tinygo3733807473/main.wasmopt
Segmentation fault (core dumped)

Thank you. Write to issue thread if you need more information.

[kripken]

Some ideas: Perhaps try to build locally with the same cmake as releases use,

https://github.com/WebAssembly/binaryen/blob/0934d6cd3abb5bc8c9ddb214eac1f7b4b1bcf899/.github/workflows/create_release.yml#L141-L143

If that doesn't work, try with docker to fully reproduce the CI build.

Hopefully one of those works, and you can make a debug build that also shows the issue, which could give us a full stack trace.

[zebreus]

I have a similar (maybe the same) issue where wasm-opt -O2 ./libarrow_python.so fails with a segfault when using the release build from github (tested 123 and 124) on ubuntu 25.04 x86_64. I attached the triggering file in libarrow_python.zip.

Here is a log from the segfault

$ wasm-opt -O2 ./libarrow_python.so --debug -o ./out.so
...
[PassRunner] running passes
[PassRunner] passes took 0 seconds.
[PassRunner] (final validation)
writing...
writing binary to ./out.so
Opening './out.so'
fish: Job 1, 'wasm-opt' terminated by signal SIGSEGV (Address boundary error)

Some things I tried:

• If I don't specify -o it does not segfault.
• With -O0 and -O1 it does not segfault.
• A build configured with just cmake . does not segfault.
• A build configured with the command from the release workflow (cmake . -G Ninja -DCMAKE_CXX_FLAGS="-static" -DCMAKE_C_FLAGS="-static" -DCMAKE_BUILD_TYPE=Release -DBUILD_STATIC_LIB=ON -DBUILD_MIMALLOC=ON -DCMAKE_INSTALL_PREFIX=install) does not segfault.
• A build configured with the command from the release workflow in a alpine docker container does segfault
• A build configured with just cmake . in a alpine docker container does segfault
• The alpine builds also segfault when executed inside the alpine docker container

[kripken]

@zebreus Can you get a stack trace from the segfault? On linux, say running in gdb? And, perhaps also a stack trace from a debug build?