-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Unique bugs deduplicated into the same issue #8389
Comments
Thanks for brining this to our attention,
This is actually the reason for the two bugs being grouped together. Currently ClusterFuzz uses a heuristic based on the top 3 stack frame entries. We have plans to revisit the way ClusterFuzz deduplicates crashes. I am not sure if having special heuristics for Rust is the way to go here, @oliverchang WDYT? |
At least for Rust-based deduplication of bugs one heuristic which might help is to skip stack frames where the demangled name starts with
We could probably work on getting some of that inlined to have fewer stack frames though if that would help too |
In these two cases, the deduplication is based on picking these things out of the stacktrace:
and
(See the "Crash State" section on the testcases). We already ignore most core::, std:: etc frames, and picked those out as the ones for use for deduplication. I'm not sure how we can improve this case unfortunately, without negatively impacting other similar cases where these may in fact be the same bug (and resulting in more bug spam). |
Is there a rule for filtering out the |
This change is an attempt to address the behavior found at google/oss-fuzz#8389 where two distinct bugs were accidentally deduplicated into the same bug report. One of the reasons for this is that the stack traces between the two bugs were almost the same with only very minor differences. My hope is that by forcing a unique stack frame per fuzzer this will be less likely since there is guaranteed to be at least one stack frame per fuzz target which is unique with this change. While I was here I wrapped up the generated function by the `fuzz_target!` macro in a `const _: () = { ... }` to avoid adding this new `run` function in to the normal module's namespace and accidentally causing name collisions (e.g. if fuzz targets already have functions named `run`)
I went ahead and sent rust-fuzz/libfuzzer#95 to update Rust's fuzzing infrastructure to ideally have at least one uniqe stack frame per fuzzer. |
Thanks! Note that this may have downsides as well -- fuzzers within the same project will have overlap. Sometimes it's quite beneficial to have these be deduplicated rather than file N bugs (for N fuzzers) for the same underlying issue with the project. |
Today I discovered a case in the Wasmtime project's fuzzing where two different fuzz bugs reported were lumped into the same issue reported on the Chromium issue tracker. The two original test cases and the corresponding issues in the Wasmtime repository are:
I believe that this is a case where oss-fuzz incorrectly categorized these two issues as the same bug in the oss-fuzz interface. The assert messages are similar (both are
assert_eq!(a, b)
failures tripping in Rust) but the actual underlying bugs were completely different. One thing we noticed was that the first ~10 stack frames are similar since that's how Rust programs are structured (panic handling machinery, etc). Is this perhaps a case where heuristics for Rust may need tweaking for determining whether two fuzz bugs are the same?cc @fitzgen
The text was updated successfully, but these errors were encountered: