docs: drop out-of-date paragraph #7403
Conversation
Issues like https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45628 aren't always reproducible with libFuzzer so to really trigger them using the OSS-Fuzz toolchain they should be built and run with engines used to trigger them originally. `reproduce` supports them now.
|
Just to clarify when the fuzz target is built with libfuzzer the buffer contains |
|
FWIW since CFLite supports libfuzzer only I couldn't use it to trigger the issue and verify the patch fixing it. It would be great if it could support AFL or honggfuzz too. |
|
What's weird is that I can trigger it with libfuzzer sometimes but with AFL, honggfuzz and valgrind it's reproducible 100% and judging by https://oss-fuzz.com/testcase-detail/4673586076450816 clusterfuzz can't trigger it with libfuzzer/asan reliably either. I'm puzzled. |
|
What's even weirder is that OSS-Fuzz reported basically the same issue in https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45636. It was found with AFL++ and isn't reliably reproducible with libFuzzer either. I wonder why they weren't deduplicated? |
Re your question on why they weren't deduplicated, it looks like the crash types / state generated from both were different enough such that ClusterFuzz considered them two separate bugs. We have a long standing bug to improve this here (google/clusterfuzz#1177), but this has some complexity that meant we haven't justified prioritising this. |
Issues like https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45628 aren't always reproducible with libFuzzer so to really trigger them using the OSS-Fuzz toolchain they should be built and run with engines used to trigger them originally. `reproduce` supports them now.
Issues like https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45628
aren't always reproducible with libFuzzer so to really trigger them using
the OSS-Fuzz toolchain they should be built and run with engines used to
trigger them originally.
reproducesupports them now.