wasm-opt segfault on merge-similar-functions with Kotlin generated wasm code

[rjaros]

Hi,

I'm using Kotlin compiler to build wasm application. Kotlin plugin is using wasm-opt to optimize wasm code. My application causes wasm-opt to crash. The wasm-opt binary is called with these parameters:

--enable-gc --enable-reference-types --enable-exception-handling --enable-bulk-memory --enable-nontrapping-float-to-int --closed-world --no-inline=kotlin.wasm.internal.throwValue --no-inline=kotlin.wasm.internal.getKotlinException --inline-functions-with-loops --traps-never-happen --fast-math --type-ssa -O3 -O3 --gufa -O3 --type-merging -O3 -Oz

The wasm code:
app.zip

When using debug option I can see it crashes when running merge-similar-functions pass.

The workaround is to replace the last parameter -Oz with -Os.

[kripken]

What version are you seeing the crash on? Latest main does not error for me. That wasm-opt command shrinks the wasm from 12 MB to less than 4.

Note that it is a large file, so your segfault may be that your machine runs out of memory. Looks like that command takes around 1 GB of RAM for me. You can try to use less by using fewer cores (BINARYEN_CORES=1 in the env, or some other small number, but it will be slower).

If none of that helps, try to run in a debugger/valgrind/asan to get more details on the specific crash.

[rjaros]

Kotlin uses version 125, but I have tested version 129 as well with the same effect. My machine has 32GB of RAM so I don't think it's a memory issue.
Some system logs:

Apr 13 16:31:58 rjaros1 audit[145703]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0
-s0:c0.c1023 pid=145703 comm="wasm-opt" exe="/home/rjaros/temp/binaryen-version_129/bin/wasm-opt" sig=11 res=1
Apr 13 16:31:58 rjaros1 kernel: show_signal_msg: 17 callbacks suppressed
Apr 13 16:31:58 rjaros1 kernel: wasm-opt[145710]: segfault at 7f0ea840dff8 ip 00007f0ea7ddc20b sp 00007f0ea840e000 error 6 in wasm
-opt[ddc20b,7f0ea702a000+1106000] likely on CPU 5 (core 5, socket 0)
Apr 13 16:31:58 rjaros1 kernel: Code: 5d 90 4c 89 6d 98 e9 d2 fc ff ff e8 7b 1e 34 00 e9 8c 11 2a ff 48 89 c3 e9 f8 11 2a ff 66 90
 55 48 89 e5 41 57 41 56 49 89 d6 <41> 55 49 89 f5 41 54 49 89 fc bf 38 00 00 00 53 48 83 ec 48 e8 6c
Apr 13 16:31:58 rjaros1 systemd-coredump[146294]: Process 145703 (wasm-opt) of user 1000 terminated abnormally with signal 11/SEGV
, processing...

[rjaros]

But runnning with BINARYEN_CORES=1 indeed fixes the problem.

[rjaros]

Crashes with BINARYEN_CORES=2 for me.

[kripken]

Interesting. Could be a stack overflow in theory. Building with ASan could check that, and get a proper stack trace. Even without ASan, a full debugger stack trace could help a lot here.

[rjaros]

Don't know if this could be important, but using wasm-opt executable provided by Fedora package binaryen-125-1.fc43.x86_64.rpm works without crash. At the same time, the same version binaryen-version_125-x86_64-linux.tar.gz downloaded from github releases page doesn't work.

[rjaros]

If it works fine with the version you build from sources and also works with the version build natively for my Fedora, but crashes with the static binary published on Github releases page, perhaps there is something wrong with these binaries?

[kripken]

Thanks, interesting, there might be a build problem then, I can confirm the builds do error.

The main things different in the releases is that they use mimalloc and static musl. I don't see a problem with mimalloc locally, so this seems like musl.

Valgrind reports Bad permissions for mapped region at address, and gdb stack trace is incredibly deep, suggesting a stack size issue. The reduced testcase does indeed have a very deep stack:

https://gist.github.com/kripken/396abcad47efcbd5002f3eb1035072bc

Further support is that, as you said, limiting cores to 1 works around this, which I confirm. 1 cores means we do not use pthreads; 2 or above uses pthreads, and their stack size depends on the default stack size of libc. So I am guessing musl/Alpine has a lower default stack size than glibc. Some searching suggests this is/was the case: Alpine uses/used 128 k vs the usual 8 MB on Linux.

We may want to make our builds force a larger stack size on Alpine. I'll also take a look at the recursion in that pass, which can maybe be avoided.

[kripken]

@rjaros fixed on main by bumping the stack size, the next release will be built that way.