jonathanmetzman

Sorry for the late response, I don't have a great guess. Do you want to email me [my last name]@chromium.org the data.csv.gz so I can try to reproduce?

>In both of these cases, we generally have only one or a few assertions that are evaluated after the harness executes, and therefore bug deduplication by stacktrace is not sufficient...

>Whether there should exist some fuzzbench mapping of bugs? You mean "where" right? I think the scheme you currently used is good for now.

>That would be awesome. Shouldn't ClusterFuzz have all the buggy versions, fixed versions, and reproducers? It would have these things (it would have a range of versions rather than the...

> BTW: For AFLGo in 2017, we modified OSS-Fuzz to accept a commit hash via [the `helper.py` script](https://github.com/aflgo/oss-fuzz/commit/05e08de8af1ea6084675eaad023e620860c7d776#diff-0ff7b5dbe0e29e090fa55e9fae2cf43fR194) and the [base-builder's `compile` script](https://github.com/aflgo/oss-fuzz/commit/05e08de8af1ea6084675eaad023e620860c7d776#diff-0ba2ab926965989d283bc172fccab8b6R34). I didn't know this. We did our...

> > What I think we could or should do instead is to create versions of oss-fuzz targets in which we can enable as many previously found bugs as possible...

>You could just take the cross-product of both approaches: If one of the approaches say two reproducers reveal different bugs, they are categorized as different bugs. Stack hashing is needed...

> I'm happy to see this discussion taking place, and it's unfortunate that I only came across it today. > I would like to point out that work in this...

I can close this issue as we've had bug based bechmarking for a while now. I am still interested in discussing using Mamga's techniques as I think it has some...

Is there a paper associated with this? Why does this modify so many things outside of fuzzers/ ? @Alan32Liu can you please run an experiment with this but not merge...