As shown below, the stability metric is not terrible, but not great. I believe the issue is multithreading, since code coverage runs with gcov show variance in mutex-related code.
See section 8 of, e.g., https://afl-1.readthedocs.io/en/latest/user_guide.html
<img width="567" alt="Screen Shot 2021-07-25 at 4 48 45 PM" src="https://user-images.githubusercontent.com/967816/126917370-564ca07b-20b2-44f8-bbaf-19600a1be402.png">
Stability by itself doesn't need to be increased if all true bugs are fully reproducible and deterministic. Though, if there is an easy way to increase it, why not?
Right, I don't see a determinism problem here. It can make the fuzzers (somewhat, not sure how to measure) less efficient though, as they chase spurious coverage differences vs. real ones. I suspect this is why some afl 'new edges' don't actually ever get merged. They were just lucky hits on mutex/etc. changes. Not a big deal, but I don't know how much effort it is.
@MarcoFalke is there something for us to follow up on here?
Not @MarcoFalke but I would guess it might be worth looking at those numbers from time to time, and if they dip a lot lower than the one I showed above, investigate thoroughly, but otherwise probably not a major concern. It is likely making things more deterministic would somewhat improve fuzzing, but the causes may be such that it would be a lot of work for modest gain.
Ok. Going to close this for now, as it's not an active bug / issue etc. If anyone actively fuzzing with afl notices an issue with the numbers they can report / let us know.