Decrease of the own finds counter

[dkasak]

I just noticed the own finds counter decreasing several times (e.g. jumping from about 34 to 20) while fuzzing with FairFuzz. I can't offhand remember whether that can ever happen in vanilla AFL (nor why it would make sense). I don't have time to investigate now, but I don't remember ever seeing it before, so it might be a FairFuzz bug.

Update: Actually, I just remembered I was running it with the -s option, which sounds like a possible culprit.

[carolemieux]

Can confirm that happens with -s, which makes sense because I just reset the queued_discovered counter after running the shadow run (see line 5696 of afl-fuzz.c). You are correct that should not happen in vanilla AFL because it only ever increments queued_discovered (at the end of common fuzz stuff).

True no side-effects would adding a shadow global that does not display on the progress bar. I'll put that fix on the list, but I don't recommend using -s for any reason other than to see the effect of fuzzing with the branch mask on the same input (it does twice the work with no reward for the first time it goes through the work). Should not happen without -s.

[dkasak]

I'll put that fix on the list, but I don't recommend using -s for any reason other than to see the effect of fuzzing with the branch mask on the same input (it does twice the work with no reward for the first time it goes through the work). Should not happen without -s.

Yes, you've explained what -s should be used for quite well elsewhere so there was no misunderstanding. :) This was exactly what I was using it for.

I can confirm that it does not seem to happen without -s. However, I have anecdotally noted that while using -s, the fuzzing session lasted several hours without problems, whereas without it it crashed relatively early on; some twenty minutes after starting it or so, with a double-free segfault. This might be a hint towards the double-free bug.

[carolemieux]

what benchmarks are you seeing this behavior in?

[dkasak]

It was when running the same binary I mentioned in #1.