-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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.
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
Cranelift: Specifically formatted valid WASM panics with 'block Insertion point not in the layout' #2347
Comments
Thank you for reporting this, @bkolobara! @alexcrichton or @fitzgen, can you take a look? |
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Nov 2, 2020
This fixes an issue where `ensure_inserted_block()` wasn't called before we do some block manipulation in the Wasmtime translation of some table-related instructions. It looks like `ensure_inserted_block()` is otherwise called on most instructions being added, so we just need to call it explicitly it seems here. Closes bytecodealliance#2347
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Nov 2, 2020
This fixes an issue where `ensure_inserted_block()` wasn't called before we do some block manipulation in the Wasmtime translation of some table-related instructions. It looks like `ensure_inserted_block()` is otherwise called on most instructions being added, so we just need to call it explicitly it seems here. Closes bytecodealliance#2347
Thanks for the report! I've minimized this a bit more as (module
(func $test (param i32) (result externref)
i32.const 0
if
else
end
local.get 0
table.get 0
)
(table 4 externref)
(export "test" (func $test))
) and it can reproduce with the CLI by just feeding in the test-case. I've got a fix at #2350 for this I believe. |
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Nov 2, 2020
This fixes an issue where `ensure_inserted_block()` wasn't called before we do some block manipulation in the Wasmtime translation of some table-related instructions. It looks like `ensure_inserted_block()` is otherwise called on most instructions being added, so we just need to call it explicitly it seems here. Closes bytecodealliance#2347
alexcrichton
added a commit
that referenced
this issue
Nov 2, 2020
This fixes an issue where `ensure_inserted_block()` wasn't called before we do some block manipulation in the Wasmtime translation of some table-related instructions. It looks like `ensure_inserted_block()` is otherwise called on most instructions being added, so we just need to call it explicitly it seems here. Closes #2347
cfallin
pushed a commit
that referenced
this issue
Nov 30, 2020
This fixes an issue where `ensure_inserted_block()` wasn't called before we do some block manipulation in the Wasmtime translation of some table-related instructions. It looks like `ensure_inserted_block()` is otherwise called on most instructions being added, so we just need to call it explicitly it seems here. Closes #2347
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have been stuck on a WASM module failing to compile under Wasmtime (0.20 and main branch) for some time now.
After a lot of trial and error I have managed to construct a minimal example that fails:
From my understanding this should be valid WASM, and tools like
wasm-validate --enable-all
also don't complain about anything, but trying to run this code withRUST_BACKTRACE=1 cargo run
results in:Note that if the empty
if-else-end block
is removed it compiles fine. Or if the externreftable.set
is removed it also works fine. But this exact instruction sequence fails.It could also be that I'm miss-understanding the WASM specification and that this is not valid WASM.
The text was updated successfully, but these errors were encountered: