Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Winch runtime segmentation fault in wasmtime 20.0.0 #8446

Closed
TerrorJack opened this issue Apr 23, 2024 · 3 comments · Fixed by #8447
Closed

Winch runtime segmentation fault in wasmtime 20.0.0 #8446

TerrorJack opened this issue Apr 23, 2024 · 3 comments · Fixed by #8447
Labels
bug Incorrect behavior in the current implementation that needs fixing winch Winch issues or pull requests

Comments

@TerrorJack
Copy link
Contributor

Reproducer: https://files.catbox.moe/jbsi1b.wasm

When wasmtime-cli-v20.0.0 is built with winch on x86_64-linux and the above file is run with wasmtime run -C compiler=winch --env PWD=/ --dir "$PWD"::/ -W tail-call -- hello.wasm, then it fails with a segmentation fault. Remove -C compiler=winch and it properly runs without any issue. The module above does not contain any opcodes unsupported by winch at this time.
@saulecabrera saulecabrera added winch Winch issues or pull requests bug Incorrect behavior in the current implementation that needs fixing labels Apr 23, 2024
@saulecabrera
Copy link
Member

Thanks for the report!

A couple of questions that might help diagnose the root cause:

  • The Wasm binary is ~25MB in size, have you tried reducing the failure with wasm-tools shrink as outlined here https://github.com/bytecodealliance/wasmtime/blob/main/docs/contributing-reducing-test-cases.md?
  • Does the Wasm program need access to the current working directory? (e.g. the command in the report is making use of --dir) If so, could you speak a bit more about what are the expectations between the program and that directory? This might make it easier to reduce the program and reproduce the bug in isolation. FWIW, I tried on a Linux machine, without the --env and without the --dir arguments and I get the following result:
main = putStrLn "hello world"

@saulecabrera
Copy link
Member

I was able to reproduce, only when the --env, --dir and -W tail-call params are specified (i.e. when -W tail-call is dropped, it doesn't segfault), which makes me think that it has to do with the tail call calling convention and its support in Winch.

saulecabrera added a commit to saulecabrera/wasmtime that referenced this issue Apr 23, 2024
@saulecabrera
winch: Handle -W tail-call
da6e185 
Fixes bytecodealliance#8446

The WebAssembly tail call proposal is currently not supported in Winch. This commit returns an error when trying to enable the tail call proposal while using Winch as the compiler. 

Even though the issue linked above doesn't make use of any of the tail instructions, the trampolines were generated using Cranelift's tail call calling convention.
@saulecabrera saulecabrera mentioned this issue Apr 23, 2024
Merged
@saulecabrera
Copy link
Member

FYI, I've opened #8447, to address this issue.

github-merge-queue bot pushed a commit that referenced this issue Apr 23, 2024
@saulecabrera
winch: Handle -W tail-call (#8447)
95ee0a2 
Fixes #8446

The WebAssembly tail call proposal is currently not supported in Winch. This commit returns an error when trying to enable the tail call proposal while using Winch as the compiler. 

Even though the issue linked above doesn't make use of any of the tail instructions, the trampolines were generated using Cranelift's tail call calling convention.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Incorrect behavior in the current implementation that needs fixing winch Winch issues or pull requests
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

winch: Handle -W tail-call saulecabrera/wasmtime
2 participants
@saulecabrera @TerrorJack