Wasmtime GitHub notifications bot (Jul 23 2022 at 00:18): Wasmtime GitHub notifications bot (Jul 23 2022 at 00:18):jameysharp commented on issue #4515:
Ooh, I am eager to look at this on Monday!
Wasmtime GitHub notifications bot (Jul 23 2022 at 00:33):github-actions[bot] commented on issue #4515:
Subscribe to Label Action
cc @fitzgen
<details>
This issue or pull request has been labeled: "fuzzing"Thus the following users have been cc'd because of the following labels:
- fitzgen: fuzzing
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 (Jul 28 2022 at 21:41):jameysharp commented on issue #4515:
It's been suggested (by a couple different people, I think, but I've lost track of who) that when we have a wasm program we want to try running, we should run it with every engine we have, not just a pair of engines.
I don't think that needs to happen in this PR. I just wanted to note that if we do want that, I think the changes I see here already cover most of the work that would be needed. So that's great!
One of my teammates also suggested that we should check that different engines agree on whether a random sequence of bytes is a valid wasm binary. That seems like another relatively small extension of this work, that somebody could build after this lands.
Wasmtime GitHub notifications bot (Jul 28 2022 at 22:24):alexcrichton commented on issue #4515:
One worry I have about running against all engines is that we run the risk of really hurting executions per second during fuzzing. When something fails I think it might be good to run in other engines to figure out which answer is probably correct, or otherwise being able to run in multiple engines easily locally would be good. While fuzzing though I think it's best to stick to just 2 engines with one guaranteed as Wasmtime
Wasmtime GitHub notifications bot (Aug 11 2022 at 20:45):abrown commented on issue #4515:
All right, I'm marking this ready for review with some caveats that I think should be addressed in subsequent PRs. At this point, the PR provides a new interface for evaluating various engines against Wasmtime but for now is only is using single-instruction modules to do so. After resolving a bunch of issues that this identified (all related to fuzz infrastructure issues, IIRC), I was able to run the target for ~3 million test cases without crashing:
#2963550 REDUCE cov: 30985 ft: 87395 corp: 1762/219Kb lim: 4096 exec/s: 394 rss: 676Mb L: 140/521 MS: 1 EraseBytes- ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: Unknown opcode 195 ignoring error: this error should be ignored by fuzzing: Unknown opcode 195 ignoring error: this error should be ignored by fuzzing: Unknown opcode 195 ignoring error: this error should be ignored by fuzzing: Unknown opcode 195 ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime #2964099 REDUCE cov: 30985 ft: 87395 corp: 1762/219Kb lim: 4096 exec/s: 394 rss: 676Mb L: 131/521 MS: 4 PersAutoDict-ShuffleBytes-ShuffleBytes-EraseBytes- DE: "\x17\x00\x00\x00\x00\x00\x00\x00"- ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtimeNote how ignored errors are printed but don't cause a crash:
wasmidoesn't understand all of the opcodes (which probably means we need to make the single-inst modules smarter to report when they use float-to-int conversions, e.g.) and Wasmtime frequently crashes when the pooling allocator picks sizes that are too small.When run with
RUST_LOG=wasmtime_fuzzing=debug cargo +nightly fuzz run differential_meta, the log output shows something like:[2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] wrote wasm file to `testcase14.wasm` [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] Evaluating: test([F32(198)]) [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] -> results on wasmi: Ok([F32(0)]) [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] -> results on wasmtime: Ok([F32(0)]) [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] Hashing instances: [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] -> hash of wasmi: 15130871412783076140 [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] -> hash of wasmtime: 15130871412783076140I expect that once the following big items are finished we could remove all other differential targets and just use this one. For now, though, I would like to get this work merged so I can stop rebasing. This is work that I think could go in different PRs (but I am certainly open for discussion on that):
- [ ] adapt V8 to the
DiffEngine/DiffInstanceinterface (@alexcrichton volunteered to look into this; the lifetime issues made this a bridge too far for this PR)- [ ] start fuzzing with the
wasm-smith-generated modules (BigModule) instead of just single-instruction modules; this is complicated by the fact thatwasm-smithwill eat up all remaining unstructured data, leaving none for choosing engines and function arguments- [ ] figure out whether to fully commit to
ModuleFeaturesand report what Wasm feature a single-instruction uses (see comments above about this)- [ ] refactor how we ignore errors: I currently do this by wrapping the error message in
DiffIgnoreErrorand downcasting theanyhowerror to see if it is one of these; @alexcrichton mentioned that he preferredResult<Option<...>>to indicate the various states but this would involve some refactoring- [ ] add more instructions to the single-instruction module generator; e.g., my next feature to add would be SIMD instructions, which would likely find some bugs and require some additional infrastructure (e.g., V128 relaxed NaN comparison)
Wasmtime GitHub notifications bot (Aug 11 2022 at 20:45):abrown edited a comment on issue #4515:
All right, I'm marking this ready for review with some caveats that I think should be addressed in subsequent PRs. At this point, the PR provides a new interface for evaluating various engines against Wasmtime but for now is only is using single-instruction modules to do so. After resolving a bunch of issues that this identified (all related to fuzz infrastructure issues, IIRC), I was able to run the target for ~3 million test cases without crashing:
#2963550 REDUCE cov: 30985 ft: 87395 corp: 1762/219Kb lim: 4096 exec/s: 394 rss: 676Mb L: 140/521 MS: 1 EraseBytes- ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: Unknown opcode 195 ignoring error: this error should be ignored by fuzzing: Unknown opcode 195 ignoring error: this error should be ignored by fuzzing: Unknown opcode 195 ignoring error: this error should be ignored by fuzzing: Unknown opcode 195 ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime #2964099 REDUCE cov: 30985 ft: 87395 corp: 1762/219Kb lim: 4096 exec/s: 394 rss: 676Mb L: 131/521 MS: 4 PersAutoDict-ShuffleBytes-ShuffleBytes-EraseBytes- DE: "\x17\x00\x00\x00\x00\x00\x00\x00"- ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtimeNote how ignored errors are printed but don't cause a crash:
wasmidoesn't understand all of the opcodes (which probably means we need to make the single-inst modules smarter to report when they use float-to-int conversions, e.g.) and Wasmtime frequently crashes when the pooling allocator picks sizes that are too small.When run with
RUST_LOG=wasmtime_fuzzing=debug cargo +nightly fuzz run differential_meta, the log output shows something like:[2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] wrote wasm file to `testcase14.wasm` [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] Evaluating: test([F32(198)]) [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] -> results on wasmi: Ok([F32(0)]) [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] -> results on wasmtime: Ok([F32(0)]) [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] Hashing instances: [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] -> hash of wasmi: 15130871412783076140 [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] -> hash of wasmtime: 15130871412783076140I expect that once the following big items are finished we could remove all other differential targets and just use this one. For now, though, I would like to get this work merged so I can stop rebasing. This is work that I think could go in different PRs (but I am certainly open for discussion on that):
- [ ] adapt V8 to the
DiffEngine/DiffInstanceinterface (@alexcrichton volunteered to look into this; the lifetime issues made this a bridge too far for this PR)- [ ] start fuzzing with the
wasm-smith-generated modules (BigModule) instead of just single-instruction modules; this is complicated by the fact thatwasm-smithwill eat up all remaining unstructured data, leaving none for choosing engines and function arguments- [ ] figure out whether to fully commit to
ModuleFeaturesand report what Wasm feature a single-instruction uses (see comments above about this)- [ ] refactor how we ignore errors: I currently do this by wrapping the error message in
DiffIgnoreErrorand downcasting theanyhowerror to see if it is one of these; @alexcrichton mentioned that he preferredResult<Option<...>>to indicate the various states but this would involve some refactoring- [ ] add more instructions to the single-instruction module generator; e.g., my next feature to add would be SIMD instructions, which would likely find some bugs and require some additional infrastructure (e.g., V128 relaxed NaN comparison)
cc: @jameysharp, @alexcrichton, @fitzgen
Wasmtime GitHub notifications bot (Aug 11 2022 at 20:58):abrown commented on issue #4515:
Oh, one other point: I have gone back and forth a few times about how to design the interface and today, at least, I'm leaning towards merging the
DiffEngineandDiffInstancetraits. Initially I separated them because logically that's how we're used to thinking about these and it is nice to be able filter out engines that won't work with a certain module. I feel like there is a way to just use theDiffInstance::instantiatefunction to do all of this. This refactoring change doesn't change the essence of the PR above, though. On a related note, the hashing interface could also change: I've been thinking through how hashing could work in the OCaml spec interpreter and, once I figure out the OCaml-Rust bindings issues, it may be that the interface ends up looking like what @alexcrichton suggested above.
Wasmtime GitHub notifications bot (Aug 18 2022 at 22:25):abrown edited a comment on issue #4515:
All right, I'm marking this ready for review with some caveats that I think should be addressed in subsequent PRs. At this point, the PR provides a new interface for evaluating various engines against Wasmtime but for now is only is using single-instruction modules to do so. After resolving a bunch of issues that this identified (all related to fuzz infrastructure issues, IIRC), I was able to run the target for ~3 million test cases without crashing:
#2963550 REDUCE cov: 30985 ft: 87395 corp: 1762/219Kb lim: 4096 exec/s: 394 rss: 676Mb L: 140/521 MS: 1 EraseBytes- ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: Unknown opcode 195 ignoring error: this error should be ignored by fuzzing: Unknown opcode 195 ignoring error: this error should be ignored by fuzzing: Unknown opcode 195 ignoring error: this error should be ignored by fuzzing: Unknown opcode 195 ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime #2964099 REDUCE cov: 30985 ft: 87395 corp: 1762/219Kb lim: 4096 exec/s: 394 rss: 676Mb L: 131/521 MS: 4 PersAutoDict-ShuffleBytes-ShuffleBytes-EraseBytes- DE: "\x17\x00\x00\x00\x00\x00\x00\x00"- ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtimeNote how ignored errors are printed but don't cause a crash:
wasmidoesn't understand all of the opcodes (which probably means we need to make the single-inst modules smarter to report when they use float-to-int conversions, e.g.) and Wasmtime frequently crashes when the pooling allocator picks sizes that are too small.When run with
RUST_LOG=wasmtime_fuzzing=debug cargo +nightly fuzz run differential_meta, the log output shows something like:[2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] wrote wasm file to `testcase14.wasm` [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] Evaluating: test([F32(198)]) [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] -> results on wasmi: Ok([F32(0)]) [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] -> results on wasmtime: Ok([F32(0)]) [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] Hashing instances: [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] -> hash of wasmi: 15130871412783076140 [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] -> hash of wasmtime: 15130871412783076140I expect that once the following big items are finished we could remove all other differential targets and just use this one. For now, though, I would like to get this work merged so I can stop rebasing. This is work that I think could go in different PRs (but I am certainly open for discussion on that):
- [ ] adapt V8 to the
DiffEngine/DiffInstanceinterface (@alexcrichton volunteered to look into this; the lifetime issues made this a bridge too far for this PR)- [x] start fuzzing with the
wasm-smith-generated modules (BigModule) instead of just single-instruction modules; this is complicated by the fact thatwasm-smithwill eat up all remaining unstructured data, leaving none for choosing engines and function arguments- [ ] figure out whether to fully commit to
ModuleFeaturesand report what Wasm feature a single-instruction uses (see comments above about this)- [ ] refactor how we ignore errors: I currently do this by wrapping the error message in
DiffIgnoreErrorand downcasting theanyhowerror to see if it is one of these; @alexcrichton mentioned that he preferredResult<Option<...>>to indicate the various states but this would involve some refactoring- [ ] add more instructions to the single-instruction module generator; e.g., my next feature to add would be SIMD instructions, which would likely find some bugs and require some additional infrastructure (e.g., V128 relaxed NaN comparison)
cc: @jameysharp, @alexcrichton, @fitzgen
Wasmtime GitHub notifications bot (Aug 18 2022 at 22:25):abrown edited a comment on issue #4515:
All right, I'm marking this ready for review with some caveats that I think should be addressed in subsequent PRs. At this point, the PR provides a new interface for evaluating various engines against Wasmtime but for now is only is using single-instruction modules to do so. After resolving a bunch of issues that this identified (all related to fuzz infrastructure issues, IIRC), I was able to run the target for ~3 million test cases without crashing:
#2963550 REDUCE cov: 30985 ft: 87395 corp: 1762/219Kb lim: 4096 exec/s: 394 rss: 676Mb L: 140/521 MS: 1 EraseBytes- ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: Unknown opcode 195 ignoring error: this error should be ignored by fuzzing: Unknown opcode 195 ignoring error: this error should be ignored by fuzzing: Unknown opcode 195 ignoring error: this error should be ignored by fuzzing: Unknown opcode 195 ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime #2964099 REDUCE cov: 30985 ft: 87395 corp: 1762/219Kb lim: 4096 exec/s: 394 rss: 676Mb L: 131/521 MS: 4 PersAutoDict-ShuffleBytes-ShuffleBytes-EraseBytes- DE: "\x17\x00\x00\x00\x00\x00\x00\x00"- ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtimeNote how ignored errors are printed but don't cause a crash:
wasmidoesn't understand all of the opcodes (which probably means we need to make the single-inst modules smarter to report when they use float-to-int conversions, e.g.) and Wasmtime frequently crashes when the pooling allocator picks sizes that are too small.When run with
RUST_LOG=wasmtime_fuzzing=debug cargo +nightly fuzz run differential_meta, the log output shows something like:[2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] wrote wasm file to `testcase14.wasm` [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] Evaluating: test([F32(198)]) [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] -> results on wasmi: Ok([F32(0)]) [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] -> results on wasmtime: Ok([F32(0)]) [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] Hashing instances: [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] -> hash of wasmi: 15130871412783076140 [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] -> hash of wasmtime: 15130871412783076140I expect that once the following big items are finished we could remove all other differential targets and just use this one. For now, though, I would like to get this work merged so I can stop rebasing. This is work that I think could go in different PRs (but I am certainly open for discussion on that):
- [ ] adapt V8 to the
DiffEngine/DiffInstanceinterface (@alexcrichton volunteered to look into this; the lifetime issues made this a bridge too far for this PR)- [x] start fuzzing with the
wasm-smith-generated modules (BigModule) instead of just single-instruction modules; this is complicated by the fact thatwasm-smithwill eat up all remaining unstructured data, leaving none for choosing engines and function arguments- [x] figure out whether to fully commit to
ModuleFeaturesand report what Wasm feature a single-instruction uses (see comments above about this)- [ ] refactor how we ignore errors: I currently do this by wrapping the error message in
DiffIgnoreErrorand downcasting theanyhowerror to see if it is one of these; @alexcrichton mentioned that he preferredResult<Option<...>>to indicate the various states but this would involve some refactoring- [ ] add more instructions to the single-instruction module generator; e.g., my next feature to add would be SIMD instructions, which would likely find some bugs and require some additional infrastructure (e.g., V128 relaxed NaN comparison)
cc: @jameysharp, @alexcrichton, @fitzgen
Wasmtime GitHub notifications bot (Aug 18 2022 at 22:25):abrown edited a comment on issue #4515:
All right, I'm marking this ready for review with some caveats that I think should be addressed in subsequent PRs. At this point, the PR provides a new interface for evaluating various engines against Wasmtime but for now is only is using single-instruction modules to do so. After resolving a bunch of issues that this identified (all related to fuzz infrastructure issues, IIRC), I was able to run the target for ~3 million test cases without crashing:
#2963550 REDUCE cov: 30985 ft: 87395 corp: 1762/219Kb lim: 4096 exec/s: 394 rss: 676Mb L: 140/521 MS: 1 EraseBytes- ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: Unknown opcode 195 ignoring error: this error should be ignored by fuzzing: Unknown opcode 195 ignoring error: this error should be ignored by fuzzing: Unknown opcode 195 ignoring error: this error should be ignored by fuzzing: Unknown opcode 195 ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtime #2964099 REDUCE cov: 30985 ft: 87395 corp: 1762/219Kb lim: 4096 exec/s: 394 rss: 676Mb L: 131/521 MS: 4 PersAutoDict-ShuffleBytes-ShuffleBytes-EraseBytes- DE: "\x17\x00\x00\x00\x00\x00\x00\x00"- ignoring error: this error should be ignored by fuzzing: unable to compile module in wasmtimeNote how ignored errors are printed but don't cause a crash:
wasmidoesn't understand all of the opcodes (which probably means we need to make the single-inst modules smarter to report when they use float-to-int conversions, e.g.) and Wasmtime frequently crashes when the pooling allocator picks sizes that are too small.When run with
RUST_LOG=wasmtime_fuzzing=debug cargo +nightly fuzz run differential_meta, the log output shows something like:[2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] wrote wasm file to `testcase14.wasm` [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] Evaluating: test([F32(198)]) [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] -> results on wasmi: Ok([F32(0)]) [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] -> results on wasmtime: Ok([F32(0)]) [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] Hashing instances: [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] -> hash of wasmi: 15130871412783076140 [2022-08-11T20:36:44Z DEBUG wasmtime_fuzzing::oracles] -> hash of wasmtime: 15130871412783076140I expect that once the following big items are finished we could remove all other differential targets and just use this one. For now, though, I would like to get this work merged so I can stop rebasing. This is work that I think could go in different PRs (but I am certainly open for discussion on that):
- [ ] adapt V8 to the
DiffEngine/DiffInstanceinterface (@alexcrichton volunteered to look into this; the lifetime issues made this a bridge too far for this PR)- [x] start fuzzing with the
wasm-smith-generated modules (BigModule) instead of just single-instruction modules; this is complicated by the fact thatwasm-smithwill eat up all remaining unstructured data, leaving none for choosing engines and function arguments- [x] figure out whether to fully commit to
ModuleFeaturesand report what Wasm feature a single-instruction uses (see comments above about this)- [x] refactor how we ignore errors: I currently do this by wrapping the error message in
DiffIgnoreErrorand downcasting theanyhowerror to see if it is one of these; @alexcrichton mentioned that he preferredResult<Option<...>>to indicate the various states but this would involve some refactoring- [ ] add more instructions to the single-instruction module generator; e.g., my next feature to add would be SIMD instructions, which would likely find some bugs and require some additional infrastructure (e.g., V128 relaxed NaN comparison)
cc: @jameysharp, @alexcrichton, @fitzgen
Wasmtime GitHub notifications bot (Aug 18 2022 at 22:26):abrown commented on issue #4515:
Ok, I've rebased this PR and included some work @alexcrichton and I did today to adapt the fuzz target to his comments above (thanks @alexcrichton!). There are still some TODOs, noted in the commit message, but this now runs without error for a decent amount of time:
$ cargo +nightly fuzz run differential_meta -s none ... === Execution rate (464537 successes / 880000 attempted modules): 52.788295454545455% (total invocations: 3525516) === #880057 REDUCE cov: 28361 ft: 150473 corp: 9884/4009Kb lim: 627 exec/s: 531 rss: 174Mb L: 546/626 MS: 1 EraseBytes- #880293 REDUCE cov: 28361 ft: 150473 corp: 9884/4009Kb lim: 627 exec/s: 530 rss: 174Mb L: 332/626 MS: 1 EraseBytes- #880511 NEW cov: 28361 ft: 150475 corp: 9885/4010Kb lim: 627 exec/s: 531 rss: 174Mb L: 622/626 MS: 3 CMP-CrossOver-ChangeByte- DE: "\x08\xa2"-
Wasmtime GitHub notifications bot (Aug 19 2022 at 00:22):alexcrichton commented on issue #4515:
Thanks again for being patient with me here @abrown! I'm happy with where this has ended up and while I think there's more to do I think it's safe to do that all as a follow-up. I'm gonna merge this and see if we can get this into the next oss-fuzz build to get our first (potentially empty?) crop of fuzz bugs.
Wasmtime GitHub notifications bot (Aug 19 2022 at 01:59):abrown commented on issue #4515:
@alexcrichton, thanks for all the help reviewing this and reworking some of the bits!
Last updated: Nov 22 2024 at 17:03 UTC