Unique bugs deduplicated into the same issue
- Dominant language
- Shell
- Stars
- 12.6k
- Forks
- 2.9k
- Avg merge
- 2d 2h
- Merged PRs (30d)
- 62
Description
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:
* https://oss-fuzz.com/testcase-detail/6653052240658432 - https://github.com/bytecodealliance/wasmtime/issues/4840
* https://oss-fuzz.com/testcase-detail/5662899036618752 - https://github.com/bytecodealliance/wasmtime/issues/4828
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
Contributor guide
Research direction
Compare OSS-Fuzz test cases 6653052240658432 and 5662899036618752 with Wasmtime issues 4840 and 4828, focusing on the deduplication heuristic and their similar Rust stack frames. Done means the two distinct bugs are categorized and reported separately without incorrectly merging them.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- testing-qa
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100