MapFeedback UserStats Can give Confusing Output

[DanBlackwell]

I sometimes see that the number of edges covered goes down in the log. After some time I think I have figured out what is happening with the code here: https://github.com/AFLplusplus/LibAFL/blob/1dcfe8ef56f38cc15c9d2205756550fda7cdf85a/libafl/src/feedbacks/map.rs#L825

In particular:

let filled = history_map.iter().filter(|&&i| i != initial).count();
...
|novelties| filled + novelties.len()

If using the MaxMapFeedback, it is possible for an input to be marked interesting because it hits a particular edge more times (say 2 times rather than 1). Let's say we initial have 'n' non-zero values in the history_map, and then we find an input with 10 edges that just cover edges we have already seen, but more times. The log will show 'n + 10' edges covered now. Then say we find a new input that covers just 1 new branch (that has never been seen before), now the log will show 'n + 1'. Seemingly our coverage has decreased.

I'm not sure if this might be how this was intended to work? If not I suppose you'll just have to either stick with outputting the value of filled (which will be one corpus entry out of date), or check that none of the novelties overlap with filled.

[domenukk]

Feel free to open a PR, sounds like you got a good idea in mind how to fix it already? It's not supposed to go down of course

[tokatoka]

i think putting filled is fine

[DanBlackwell]

Have submitted a PR which should give the fully up to date count now.

[tokatoka]

this is done