Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

qcms doesn't have much as much coverage as it should. #5380

Closed
jrmuizel opened this issue Mar 13, 2021 · 8 comments · Fixed by #5385
Closed

qcms doesn't have much as much coverage as it should. #5380

jrmuizel opened this issue Mar 13, 2021 · 8 comments · Fixed by #5385

Comments

@jrmuizel
Copy link
Contributor

If you look at the new Rust coverage reports for qcms, the coverage is really limited with the initial lines of the fuzz harness only being executed 4 times:
https://storage.googleapis.com/oss-fuzz-coverage/qcms/reports/20210312/linux/src/mozilla-central/gfx/qcms/fuzz/fuzz_targets/fuzz_target_qcms.rs.html

Given the size of the corpus this doesn't seem correct. Further, there are open crashes for areas of the code not covered by the coverage report.

@inferno-chromium
Copy link
Collaborator

@catenacyber - does your recent fix fix this ?

@catenacyber
Copy link
Contributor

catenacyber commented Mar 14, 2021

@jrmuizel thanks for this report.
I do not have access to the current corpus to test.
But I hope #5385 should fix this. (my guess is that the 4th input from your corpus stops the run)

As rustc optimizations are disabled to build the fuzz targets for coverage cf rust-lang/rust#82144
this turns on https://doc.rust-lang.org/rustc/codegen-options/index.html#debug-assertions

Could you try locally with the corpus downloaded to path/to/corpus/ and using #5385 ?

python3 infra/helper.py build_image --no-pull base-builder
python3 infra/helper.py build_fuzzers --sanitizer=coverage qcms
python3 infra/helper.py coverage --fuzz-target fuzz --corpus-dir path/to/corpus/ qcms

You can also check the log from the fuzz target running on the coverage in the file build/out/qcms/logs/fuzz.log

@jrmuizel
Copy link
Contributor Author

Yeah, it's believable that debug_asserts! would be causing this. qcms triggers debug_asserts! in weird scenarios so they're not usable for fuzzing.

@catenacyber
Copy link
Contributor

Let me know if it improves in the next few days

@jrmuizel
Copy link
Contributor Author

I think qcms coverage runs may also fail because of overflow checks that trigger that wouldn't trigger in release builds.

@catenacyber
Copy link
Contributor

Buffer overflow or integer overflow ?
Integer overflows are parts of debug_asserts I think.

@jrmuizel
Copy link
Contributor Author

Interger overlow. But you're right, those checks are disabled by RUSTFLAGS="-C debug-assertions=no"

@jrmuizel
Copy link
Contributor Author

The latest coverage report looks a lot better:
https://storage.googleapis.com/oss-fuzz-coverage/qcms/reports/20210315/linux/src/mozilla-central/gfx/report.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants