Wasmtime GitHub notifications bot (Aug 08 2020 at 02:00): Wasmtime GitHub notifications bot (Aug 08 2020 at 02:00):github-actions[bot] commented on Issue #2120:
Subscribe to Label Action
cc @bnjbvr
<details>
This issue or pull request has been labeled: "cranelift", "cranelift:wasm"Thus the following users have been cc'd because of the following labels:
- bnjbvr: cranelift
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
Wasmtime GitHub notifications bot (Aug 10 2020 at 14:12):alexcrichton commented on Issue #2120:
Out of curiosity, I wonder if we could collaborate a bit on fuzzing for these test cases? We get a good deal of fuzzing with oss-fuzz on Wasmtime, but our fuzz generators for wasm files aren't always the best (right now it's just
wasm-opt -ttfwhich I think is somewhat limited). Do you know if it'd be possible to see if we could share generators for wasm files so we could leverage the oss-fuzz infrastructure to discover cases like this?(also we can move this to a separate issue to avoid cluttering up too much here)
Wasmtime GitHub notifications bot (Aug 10 2020 at 15:35):fitzgen commented on Issue #2120:
Do you know if it'd be possible to see if we could share generators for wasm files so we could leverage the oss-fuzz infrastructure to discover cases like this?
+1
I remember a talk at the Berlin all hands about how SpiderMonkey folks are using libFuzzer, but I don't remember what the approach to generating Wasm test cases was (or if it was discussed at all).
AFAIK,
wasm-op -ttfwill only generate core wasm, which makes sense given that the SM fuzzing has been finding multi-value bugs.Coincidentally, I started writing a new wasm test case generator over the weekend, and I intend to support Wasm proposals (on a configurable basis).
But yeah, we should ask decoder what test case generator he is using when fuzzing SM.
Last updated: Oct 23 2024 at 20:03 UTC