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.

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

lightbeam panicked when either run or wasm2obj #2379

Closed
qinxk-inter opened this issue Nov 9, 2020 · 4 comments
Closed

lightbeam panicked when either run or wasm2obj #2379

qinxk-inter opened this issue Nov 9, 2020 · 4 comments
Labels
bug Incorrect behavior in the current implementation that needs fixing lightbeam Issues related to the Lightbeam compiler

Comments

@qinxk-inter
Copy link

- What are the steps to reproduce the issue?
t.wasm is wat2wasm from below text:

(module
  (func $add (param $lhs i32) (param $rhs i32) (result i32)
    get_local $lhs
    get_local $rhs
    i32.add)
  (export "add" (func $add))
)

./wasmtime run --lightbeam t.wasm 1 2
./wasmtime wasm2obj --lightbeam t.wasm t.obj
- What do you expect to happen? What does actually happen? Does it panic, and
if so, with which assertion?

Expect to be run without any issue. Got error with the output:

thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', /PATH/wasmtime/crates/lightbeam/src/backend.rs:637:35
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

- Which Wasmtime version / commit hash / branch are you using?
main latest by now, commit 12e658a
- If relevant, can you include some extra information about your environment?
(Rust version, operating system, architecture...)
rustc 1.45.2, MacOS

@qinxk-inter qinxk-inter added the bug Incorrect behavior in the current implementation that needs fixing label Nov 9, 2020
@bjorn3
Copy link
Contributor

bjorn3 commented Nov 9, 2020

The panic happens at

let func_start = &mut self.func_starts[func_idx as usize];

func_starts should be filled at

let func_starts = iter::repeat_with(|| (None, assembler.new_dynamic_label()))
.take(func_count as usize)
.collect::<Vec<_>>();

func_count gets it's value from

let mut codegen_session: CodeGenSession<_> = CodeGenSession::new(
translation.function_body_inputs.len() as u32,
&env,
lightbeam::microwasm::I32,
);

All elements in function_body_inputs are taken just before at

let functions = mem::take(&mut translation.function_body_inputs);
leaving the count at zero.

@alexcrichton
Copy link
Member

The lightbeam backend is known to currently have many bugs in it and is not tested on CI. It's not recommended for widespread usage. Thanks for the report, though, this is good to know when someone gets around to fixing lightbeam issues!

@alexcrichton alexcrichton added the lightbeam Issues related to the Lightbeam compiler label Nov 9, 2020
@daubaris
Copy link

daubaris commented Nov 9, 2020

Are the lengths of translation.function_body_input and translation.native_signatures always the same or can they be different in some situations?

@alexcrichton
Copy link
Member

Lightbeam was removed in #3390 as explained in RFC 14, so I'm going to close this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Incorrect behavior in the current implementation that needs fixing lightbeam Issues related to the Lightbeam compiler
Projects
None yet
Development

No branches or pull requests

4 participants