binaryen icon indicating copy to clipboard operation
binaryen copied to clipboard

Replicating wasm-reduce's "expected behavior on canonicalized (read-written) binary"

Open willcohen opened this issue 3 years ago • 1 comments

In attempting to use wasm-reduce to identify test cases for a WASM file that GraalWasm is unable to parse, the reducer is unable to proceed because the error disappears after when testing the read-written binary. As I understand it, the read-write test is basically just running wasm-opt per wasm-reduce.cpp, but attempting to pass the wasm through wasm-opt manually with those options doesn't provide a file that can get through the test.

In the following code, foo.sh tries to run GraalWasm to parse the WASM file, and greps the error output to return just the parsing failure text.

$ wasm-reduce fail.wasm "--command=bash foo.sh" -t test.wasm -w work.wasm -to 10 -b "/nix/store/n1hdj09vz7wh420v15f2fla298jjcrlb-binaryen-109/bin"
|applying timeout: 10
|wasm-reduce
|input: fail.wasm
|test: test.wasm
|working: work.wasm
|bin dir: /nix/store/n1hdj09vz7wh420v15f2fla298jjcrlb-binaryen-109/bin/
|extra flags: -all
|expected result:
[ProgramResult] code: 512 stdout:
Asynchronous parsing failed.
[====]
in 1.95494 seconds
[/ProgramResult]

|!! Make sure the above is what you expect! !!

|checking that command has different behavior on different inputs (this verifies that the test file is used by the command)
|checking that command has expected behavior on canonicalized (read-written) binary
|! running command on the canonicalized module should give the same results
[ProgramResult] code: 512 stdout:
[====]
in 1.28602 seconds
[/ProgramResult]

Fatal: |! stopping, as it is very unlikely reduction can succeed (use -f to ignore this check)

$ wasm-opt fail.wasm -o fail2.wasm
warning: no passes specified, not doing any work

$ wasm-reduce fail2.wasm "--command=bash foo.sh" -t test.wasm -w work.wasm -to 10 -b "/nix/store/n1hdj09vz7wh420v15f2fla298jjcrlb-bi
naryen-109/bin"
|applying timeout: 10
|wasm-reduce
|input: fail2.wasm
|test: test.wasm
|working: work.wasm
|bin dir: /nix/store/n1hdj09vz7wh420v15f2fla298jjcrlb-binaryen-109/bin/
|extra flags: -all
|expected result:
[ProgramResult] code: 512 stdout:
Asynchronous parsing failed.
[====]
in 1.46061 seconds
[/ProgramResult]

|!! Make sure the above is what you expect! !!

|checking that command has different behavior on different inputs (this verifies that the test file is used by the command)
|checking that command has expected behavior on canonicalized (read-written) binary
|! running command on the canonicalized module should give the same results
[ProgramResult] code: 512 stdout:
[====]
in 1.28536 seconds
[/ProgramResult]

Fatal: |! stopping, as it is very unlikely reduction can succeed (use -f to ignore this check)

willcohen avatar Jul 21 '22 15:07 willcohen

Not sure I follow the first paragraph: are you saying that read-write using wasm-opt does preserve the issue, but when wasm-reduce does a read-write it doesn't?

wasm-opt does not roundtrip 100% (due to how it handles stacky code), so that might be an issue. But it should happen with both wasm-opt and wasm-reduce calling wasm-opt. If just in one then it could be a bug - if so, please provide the wasm file and script to reproduce.

kripken avatar Jul 21 '22 18:07 kripken

Closing this issue. The fault was in the foo.sh script running the command providing the condition, not any of the tools here.

willcohen avatar Dec 29 '22 20:12 willcohen