bytecodealliance
fuzz: differential V8 engine occasionally crashes
Test Case
No test case produced.
Steps to Reproduce
$ ALLOWED_ENGINES=-spec,-wasmi cargo +nightly fuzz run differential -s none
Run for enough time to crash.
Expected Results
Not to crash.
Actual Results
...
=== Execution rate (1023 successes / 6000 attempted modules): 17.05% ===
wasmi: 0.00%, spec: 0.00%, wasmtime: 87.70%, v8: 12.30%
wasm-smith: 44.81%, single-inst: 55.19%
...
#6851 NEW cov: 20559 ft: 63794 corp: 1188/146Kb lim: 170 exec/s: 360 rss: 106Mb L: 138/170 MS: 2 CopyPart-CopyPart-
#6862 NEW cov: 20559 ft: 63795 corp: 1189/146Kb lim: 170 exec/s: 361 rss: 106Mb L: 132/170 MS: 1 CopyPart-
#6864 NEW cov: 20560 ft: 63796 corp: 1190/146Kb lim: 170 exec/s: 361 rss: 106Mb L: 103/170 MS: 2 EraseBytes-ChangeBit-
#6869 NEW cov: 20563 ft: 63809 corp: 1191/146Kb lim: 170 exec/s: 361 rss: 106Mb L: 169/170 MS: 5 ShuffleBytes-InsertRepeatedBytes-InsertRepeatedBytes-ShuffleBytes-PersAutoDict- DE: "\xff\xff\xff\x07"-
#6988 NEW cov: 20563 ft: 63838 corp: 1192/146Kb lim: 170 exec/s: 349 rss: 106Mb L: 129/170 MS: 4 InsertRepeatedBytes-ChangeBit-EraseBytes-InsertRepeatedBytes-
────────────────────────────────────────────────────────────────────────────────
Error: Fuzz target exited with signal: 11 (core dumped)
Versions and Environment
Wasmtime version or commit: main
Operating system: Fedora 35
Architecture: x86_64
cc: @alexcrichton, guess that crash we saw wasn't the spec interpreter after all.
I haven't been able to reproduce this locally unfortunately. When I let the fuzzer run long enough it hit https://github.com/bytecodealliance/wasmtime/issues/4812 before hitting this fault.
Can you try running the fuzzer in gdb to see if you can grab a stack trace of the fault? (presuming it doesn't take too long to fault). When using gdb though it's difficult b/c segfaults can normally happen for wasm and there's no great way to handle this. I was able to do handle SIGILL nostop locally in gdb but if you do handle SIGSEGV nostop I think that when it actually hits the crashing failure it lets the process exit which is no good, so you may have to babysit it a bit and double-check that SIGSEGV doesn't look like a normal wasm SIGSEGV (rr might be super helpful here in this regard)
Maybe you can do handle SIGSEGV nostop but also add a breakpoint where the signal handler propagates the SIGSEGV if it didn't originate from the wasm module?
