afonso360 opened PR #3299 from fuzzer-brtable
to main
:
Hey!
A small addition #3094. This is the last planned branch instruction for the CLIF fuzzer (since it looks like
brif
/brff
are going to be removed), and means that we have completed the branch / jump part of the fuzzer :tada:This change independently found #3100 which was fixed in #3282.
afonso360 edited PR #3299 from fuzzer-brtable
to main
:
Hey!
A small addition to #3094. This is the last planned branch instruction for the CLIF fuzzer (since it looks like
brif
/brff
are going to be removed), and means that we have completed the branch / jump part of the fuzzer :tada:This change independently found #3100 which was fixed in #3282.
cfallin submitted PR review.
cfallin submitted PR review.
cfallin created PR review comment:
The "empty blockparams" condition is of course necessary, but how do we guard against cases where no blocks fit this requirement, and we end up doing a
choose()
on an empty list (which will panic)? Possibly I'm just missing this invariant elsewhere -- if so, could you add a comment describing why it'll always succeed, and maybe anassert!(target_blocks.len() > 0)
or somesuch?
afonso360 created PR review comment:
This already happens all the time. i.e. we are never guaranteed to generate variables of any type, so any instruction that requests a value of a type that doesn't exist ends up doing a choose on an empty block.
What ends up happening here, is that choose returns an error, we bubble the error up and into cargo-fuzz, which marks this input as invalid and starts another round of fuzzing.
afonso360 submitted PR review.
afonso360 edited PR review comment.
cfallin submitted PR review.
cfallin created PR review comment:
Ah, great, the key bit is that the failure bubbles up; I couldn't recall if
choose()
just panics in this case instead. All good then -- I'll go ahead and merge, thanks!
afonso360 edited PR review comment.
afonso360 edited PR review comment.
cfallin merged PR #3299.
Last updated: Dec 23 2024 at 12:05 UTC