Evgeny Vereshchagin

> Trick : You should pass -runs = 2 to the reproducer libfuzzer command to get it >> Looks like it works. Thanks! I think it should probably be documented...

> a full fix to either of these I'm wondering what the use case is? Since CIFuzz uses coverage reports and corpora tightly linked to the main branches I don't...

> let's focus on stopping to fuzz the wrong code and still have a green CI, first Looks like the best way to address that would be to document the...

Dunno. This PR introduces a bunch of untested code that is unlikely to be tested by actual projects (because apart from few projects like systemd nobody cares about their forks...

> @evverx that's not the case, please have a closer look I did. I didn't say that there were no tests. I said that this code is unlikely to be...

> that annoyance is helpful to make users aware of fuzzing the wrong code CIFuzz users are projects where CIFuzz usually works and they are unlikely to even see that....

>> it isn't clear what the point of watching OSS-Fuzz for 2 weeks is > The idea was to support users coming to google/oss-fuzz asking related questions or for related...

> I would argue that the OSS-Fuzz bug tracker is the right place for that, because it's the home to CIFuzz. In an ideal world I'd agree to some extent...

> We can only guess what users will do in practice I'm a user and I'm already trying to say that the documentation is missing and the error messages aren't...

If it's an ARM machine I suspect it's a variation on https://github.com/google/oss-fuzz/pull/9727 in the sense that it seems that x86_64 and aarch64 images are mixed up somehow.