Segfault with exceptions + single-pass regalloc

[alexcrichton]

Using Wasmtime 37.0.2 I get:

$ wasmtime wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes -Oregalloc-algorithm=single-pass -Wexceptions=y tests/spec_testsuite/proposals/wasm-3.0/throw.wast

thread 'main' panicked at /home/runner/work/wasmtime/wasmtime/crates/unwinder/src/exception_table.rs:168:25:
Wasmtime exception unwind info only supports dynamic contexts on the stack
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
zsh: IOT instruction (core dumped)  wasmtime wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes

using main I get:

$ cargo run wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes -Oregalloc-algorithm=single-pass -Wexceptions=y tests/spec_testsuite/proposals/wasm-3.0/throw.wast
...
zsh: segmentation fault (core dumped)  cargo run wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes

My guess is that this is related to the single-pass register allocator, so cc @d-sonuga

[alexcrichton]

Another example is:

$ cargo run wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes -Oopt-level=0 -Oregalloc-algorithm=single-pass -Wexceptions,function-references ./tests/spec_testsuite/proposals/wasm-3.0/try_table.wast
...
zsh: segmentation fault (core dumped)  cargo run wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes

When -Oopt-level=0 is removed this yields:

$ cargo run wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes -Oregalloc-algorithm=single-pass -Wexceptions,function-references ./tests/spec_testsuite/proposals/wasm-3.0/try_table.wast
...
Error: failed to run script file './tests/spec_testsuite/proposals/wasm-3.0/try_table.wast'

Caused by:
    0: failed directive on ./tests/spec_testsuite/proposals/wasm-3.0/try_table.wast:302
    1: result 0 didn't match
    2: expected                  5 / 0x0000000000000005
       actual                    0 / 0x0000000000000000

[d-sonuga]

Hey @alexcrichton, how do I run the fuzzer on macOS. I tried cargo +nightly fuzz run wast_tests but I get this OCaml-related build error: failed to run custom build command for wasm-spec-interpreterandFailed to build the OCaml library using 'make'.`
Is there any OCaml-specific setup I need to do first?

[alexcrichton]

That command's the one yeah. To disable the need for ocaml you can pass --no-default-features and I would also recommend passing --sanitizer none as it speeds up fuzzing by a fair bit too (and compilation!)

[d-sonuga]

Thanks!
But there's another issue: after running for a few seconds, it fails, but when I try to rerun the failed input, it passes, and I don't think this particular failure has anything to do with the allocator.

[alexcrichton]

Could you paste an example of what the failure looks like? For wast_tests I'm not aware of any failures like that. For differential I know of one esoteric failure (possibly), but I'm not sure if you're running into that

[d-sonuga]

Here's one:

==30721== ERROR: libFuzzer: deadly signal
NOTE: libFuzzer has rudimentary signal handlers.
      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
SUMMARY: libFuzzer: deadly signal
MS: 2 CrossOver-CopyPart-; base unit: 5fca8986ed075873381dbb53bd351e47403b848b
0x0,0xff,0xff,0x1,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x3e,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x80,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x81,0x81,0x81,0x81,0x81,0x81,0x81,0xff,0x81,0x81,0x81,0x81,0xff,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0xd7,0xd7,0xd7,0xd7,0xd7,0xd7,0xd7,0xd7,0x0,0xff,0x0,0x0,0x0,0x0,0x0,0x26,0x0,0x0,0x58,0x58,0x58,0x58,0x58,0x58,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x58,0x58,0x58,0x5a,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x0,0x0,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x5d,0x58,0x58,0x0,0x0,
\000\377\377\001\000\000\000\000\000\000\000\000\000XXXXXXXX>\000\000\000\000\000\000\000\200XXXXXXXXXX\201\201\201\201\201\201\201\377\201\201\201\201\377XXXXXXXXXXXXXXXXXX\327\327\327\327\327\327\327\327\000\377\000\000\000\000\000&\000\000XXXXXX\000\000\000\000\000\000\000\000\000XXXZXXXXXXXXXX\000\000XXXXXXXXXX]XX\000\000
artifact_prefix='/Users/d-sonuga/repos/wasmtime/fuzz/artifacts/wast_tests/'; Test unit written to /Users/d-sonuga/repos/wasmtime/fuzz/artifacts/wast_tests/crash-2571966bf9ef0f84826111ad1295349fc069e71f
Base64: AP//AQAAAAAAAAAAAFhYWFhYWFhYPgAAAAAAAACAWFhYWFhYWFhYWIGBgYGBgYH/gYGBgf9YWFhYWFhYWFhYWFhYWFhYWFjX19fX19fX1wD/AAAAAAAmAABYWFhYWFgAAAAAAAAAAABYWFhaWFhYWFhYWFhYWAAAWFhYWFhYWFhYWF1YWAAA

────────────────────────────────────────────────────────────────────────────────

Failing input:

	fuzz/artifacts/wast_tests/crash-2571966bf9ef0f84826111ad1295349fc069e71f

Output of `std::fmt::Debug`:

	[0, 255, 255, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 88, 88, 88, 88, 88, 88, 88, 88, 62, 0, 0, 0, 0, 0, 0, 0, 128, 88, 88, 88, 88, 88, 88, 88, 88, 88, 88, 129, 129, 129, 129, 129, 129, 129, 255, 129, 129, 129, 129, 255, 88, 88, 88, 88, 88, 88, 88, 88, 88, 88, 88, 88, 88, 88, 88, 88, 88, 88, 215, 215, 215, 215, 215, 215, 215, 215, 0, 255, 0, 0, 0, 0, 0, 38, 0, 0, 88, 88, 88, 88, 88, 88, 0, 0, 0, 0, 0, 0, 0, 0, 0, 88, 88, 88, 90, 88, 88, 88, 88, 88, 88, 88, 88, 88, 88, 0, 0, 88, 88, 88, 88, 88, 88, 88, 88, 88, 88, 93, 88, 88, 0, 0]

Reproduce with:

	cargo fuzz run --no-default-features --sanitizer=none wast_tests fuzz/artifacts/wast_tests/crash-2571966bf9ef0f84826111ad1295349fc069e71f

Minimize test case with:

	cargo fuzz tmin --no-default-features --sanitizer=none wast_tests fuzz/artifacts/wast_tests/crash-2571966bf9ef0f84826111ad1295349fc069e71f

────────────────────────────────────────────────────────────────────────────────

Error: Fuzz target exited with exit status: 77

[alexcrichton]

Hm ok that I'm not sure about. I'll run locally and see if I can reproduce as well.

Using RUST_LOG=wasmtime_fuzzing it looks like that test is executing a threads-related test, so it might have something to do with that? Not that that's helpful alas :(