Wasmtime GitHub notifications bot (Dec 20 2022 at 19:02): Wasmtime GitHub notifications bot (Dec 20 2022 at 19:02):github-actions[bot] commented on issue #5482:
Subscribe to Label Action
cc @fitzgen
<details>
This issue or pull request has been labeled: "cranelift", "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 (Dec 21 2022 at 10:02):afonso360 commented on issue #5482:
Trevor tells me that he ran this fuzz target for four hours without finding any bugs, which actually has me concerned that it may not be testing what we wanted to test.
That's weird, when I ran this it crashed almost immediately even without a previous corpus.
Ran it again with (This is just the run string that I usually use for fuzzgen):
cargo +nightly fuzz run --no-default-features cranelift-compile -- -rss_limit_mb=8192 -max_len=128 -runs=5000000Gives me the following input (base64'd):
////L/////////////////8K/wAAXQAAAAD/AQAAAA==Crashes with:
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Undeclared function u0:0 is referenced by u1:0!', fuzz/fuzz_targets/cranelift-compile.rs:60:53 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Wasmtime GitHub notifications bot (Dec 21 2022 at 12:46):afonso360 commented on issue #5482:
A follow up from the issue above, the default fuzzgen config generates random function references even if they don't actually exist. This works for icache, but not for fuzzgen since there we actually try to do some linking (via cranelift-jit).
Altering that config for this target does get it past that error.
Wasmtime GitHub notifications bot (Dec 21 2022 at 12:47):afonso360 edited a comment on issue #5482:
A follow up from the issue above, the default fuzzgen config generates random function references even if they don't actually exist. This works for icache, but not for fuzzgen (and compile) since there we actually try to do some linking (via cranelift-jit).
Altering that config for this target does get it past that error.
Wasmtime GitHub notifications bot (Dec 21 2022 at 18:11):jameysharp commented on issue #5482:
Huh, I guess I'm surprised that
cranelift-jitworks at all for cross-compiling. I don't think we should try to test those code paths when cross-compiling. So I think this is another argument for merging this new fuzz target intocranelift-icache, or at least making it more closely resemble that fuzz target.
Wasmtime GitHub notifications bot (Jan 03 2023 at 15:41):alexcrichton commented on issue #5482:
Could this perhaps get added as a mode to
cranelift-fuzzgeninstead of adding a new fuzz-target? Mostly due to how oss-fuzz allocates time I think it would be best to not expand the time allocated for Cranelift-specific fuzzing since the time alloted to cranelift-fuzzgen is probably good enough, although I could see this going both ways.My thinking is that the first byte of the input, for example, and its lowest bit would indicate "run in an interpreter" or "compile, possibly a cross-compile"
Wasmtime GitHub notifications bot (Jan 03 2023 at 15:48):afonso360 commented on issue #5482:
Merging this into icache would have the same effect right? We would keep the same number of targets as we do today (i.e.
fuzzgenandicache). I think that would be the best way to go.
Wasmtime GitHub notifications bot (Jan 03 2023 at 15:49):alexcrichton commented on issue #5482:
Oh dear sorry disregard me, indeed!
Last updated: Nov 22 2024 at 16:03 UTC