Stream: general

Topic: Asyncify "assertion failed: (canMakeZero(type))"


view this post on Zulip Piotr Sarnacki (Feb 08 2025 at 10:23):

I'm trying to use asyncify in a decently sized WASM binary and I'm having trouble to debug it. Unfortunately the error message is quite cryptic, even with --debug:

Assertion failed: (canMakeZero(type)), function makeZero, file literal-utils.h, line 35.

I think the problem is with a value that can't be made into a default "zero like" value, but it's been hard to find the exact spot and after finding the spot I'm still not sure what's the best way to deal with it.

For debugging I got the best result when running asyncify on a WAT file, but while it worked for small, hand formatted files, unfortunately the WAT format that tools I use output is incompatible with wasm-opt, like for example it expects the instructions in the list form. I tried to remedy that by generating a WAT file with wasm-tools print -f intput.wasm > output.wat, but unfortunately it complains about legacy exceptions:

error: legacy-exceptions not supported

At some point I might try to output a WAT that is formatted in a way wasm-opt expects, but for now I resorted to try to debug it otherwise, ie. remove parts of code from a WAT file, convert it to WASM and then try to asyncify.

While removing various functions I figured out that the likely offender is the following function:

(func $create_string_from_array (;66;) (type 74) (param $data (ref $CharArray)) (result (ref $String))
  local.get $data
  local.get $data
  array.len
  struct.new $String
  return
)

In order to test my hypothesis I changed the result to be (ref null $String) and I added a ref.cast (ref $String) call after each of the create_string_from_array function calls. After doing that wasm-opt no longer complains. The problem is that while I could leave it like that for this particular function, I have many more functions returning a non-null reference and I think the only reason why wasm-opt doesn't complain is because they're not called in the entrypoint and if I add unwind/rewind calls, it will complain about other occurrences of non-null returns.

Is there any way around it? I'm guessing not likely, knowing roughly how asyncify works, but there was very little info about this particular aspect that I could find.

view this post on Zulip Piotr Sarnacki (Feb 16 2025 at 15:38):

So, it turns out there is an issue about that, which explains the problem: https://github.com/WebAssembly/binaryen/issues/6990. Sorry for posting without searching properly.


Last updated: Feb 28 2025 at 02:27 UTC