Conversation
|
No issues other than #1484 discovered after 75 million iterations |
|
|
||
| [dependencies.rav1d] | ||
| path = ".." | ||
| default-features = false # Disables ASM; comment out to enable |
There was a problem hiding this comment.
Does fuzzing not work with asm enabled? or is this to get coverage on the non-assembly versions?
In practice, assembly is always enabled as speed is otherwise unacceptable and I imagine it would speed up fuzzing too.
If this has to stay off, could you document the reason?
| let mut settings = rav1d::rust_api::Settings::new(); | ||
| settings.set_logger_enabled(false); | ||
| settings.set_frame_size_limit(256 * 256); // in pixels, 256x256 image max | ||
| let mut dec = rav1d::rust_api::Decoder::with_settings(&settings).expect("failed to create decoder instance"); |
There was a problem hiding this comment.
Should we bound the worker count? I think you get one worker per logical CPU.
My worry is that this could cause a slowdown if someone runs multiple parallel fuzz jobs.
| // Handle all pending pictures before sending the next data. | ||
| handle_pending_pictures(&mut dec, false)?; |
There was a problem hiding this comment.
Could we add an end-of-input drain after this call? send_data() accepting the buffer doesn’t mean decoding is finished, and a single get_picture() can return TryAgain while threaded decoding is still pending, or return only the first of several pictures.
This could let the fuzzer cover more of the decoder logic.
2 participants
cargo fuzzThis is essentially #1475 but rebased on top of main. It has already discovered an issue: #1476