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

[fuzz] Fix order of arguments passed in to wasm-spec-interpreter #4672

Merged
merged 1 commit into from
Aug 10, 2022
Merged

[fuzz] Fix order of arguments passed in to wasm-spec-interpreter #4672

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion crates/fuzzing/wasm-spec-interpreter/ocaml/interpret.ml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -55,7 +55,7 @@ let extract_exported_func export = match export with
(** Interpret the first exported function and return the result. Use provided
parameters if they exist, otherwise use default (zeroed) values. *)
let interpret_exn module_bytes opt_params =
let opt_params_ = Option.map (List.map convert_to_wasm) opt_params in
let opt_params_ = Option.map (List.rev_map convert_to_wasm) opt_params in
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a bug in the official wasm interpreter?

Copy link
Contributor

@conrad-watt conrad-watt Aug 10, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Internally, the interpreter represents the value stack as a list in reverse order, so that popping from the stack is equivalent to taking the head of the list.

My tweaked version of the interpreter exposes an entrypoint function that assumes this reversal has already happened, hence the confusion. When I cut a new version of my interpreter, I can investigate if it makes sense to push the reversal down further, but an advantage of doing it this way is that the rev and map operations can be carried out here simultaneously, which is more efficient.

let module_ = parse module_bytes in
let m_isa = Ast_convert.convert_module (module_.it) in
let fuel = Z.of_string "4611686018427387904" in
Expand Down
11 changes: 11 additions & 0 deletions crates/fuzzing/wasm-spec-interpreter/src/with_library.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -119,4 +119,15 @@ mod tests {
])]
);
}

// See issue https://github.com/bytecodealliance/wasmtime/issues/4671.
#[test]
fn order_of_params() {
let module = wat::parse_file("tests/shr_s.wat").unwrap();

let parameters = Some(vec![Value::I32(1795123818), Value::I32(-2147483648)]);
let results = interpret(&module, parameters.clone()).unwrap();

assert_eq!(results, vec![Value::I32(1795123818)]);
}
}
9 changes: 9 additions & 0 deletions crates/fuzzing/wasm-spec-interpreter/tests/shr_s.wat
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
(module
(type (;0;) (func (param i32 i32) (result i32)))
(func (;0;) (type 0) (param i32 i32) (result i32)
local.get 0
local.get 1
i32.shr_s
)
(export "test" (func 0))
)