Question about `StdState`, `AflStatsStage` and `ClientStats`

[Evian-Zhang]

As mentioned in the description of #2969 , to make monitors work better, one of the following works is to add more necessary statistics. After reading the source code, I realized that statistics are related to three core structures: StdState, AflStatsStage, and ClientStats.

I'm totally aware of what these structures are designed to do and why they are designed to be split into three structures:

• StdState is used to maintain fuzzing states, and provide those statistics to others who need it.
• AflStatsStage is used to emit fuzzer_stats abd plot_data file after each cycle.
• ClientStats is used to maintain statistics for monitors to display.

However, I find there are some inconsistencies among these structures, and I don't know the reason, which prevents me from refactoring these codes.

For example, there is a last_found_time in StdState which is used to report the last time something was added to the corpus, and is designed to be accessed by HasLastReportTime trait (although nobody uses this). However, instead of taking this data from the state, the AflStatsStage individually maintains a last_find field by probing the scheduled count. Moreover, it also maintains a last_crash and a last_hang, which the StdState lacks.

So my question is: should I refactor those codes to keep every useful data in StdState, and retrieve those data in AflStatsStage and ClientStats by related traits (such as HasLastReportTime)? If not, by what rule should I decide to maintain certain statistics in one of these three structures?

[domenukk]

The real answer is that it was developed by different people at different times (the Afl stuff mostly by @R9295 , for example).
Ideally everything should be done in the monitor, IMHO, even writing the afl stats - however, this would be conceptually more complex.
In any case it'd be amazing to clean this up, definitely feel free to refactor!

[Evian-Zhang]

Hmm, I remember that one of LibAFL's cool features is we don't need to re-run corpus if we resume a previously stopped fuzzing. Does this feature depend on the state? If so, I think the statistics should be maintained by states.

[domenukk]

Yes that's part of the state. However, keep in mind that everything we put in state will make restarts slower (as they need to serialize & deserialize that). So ideally keep minimal info in State, I'd prefer to have imprecise stats over loosing fuzzing performance, personally

Or we even add some extra information that only gets written on quit but not during normal timeouts/crashes(?)

[Evian-Zhang]

Ok I understand. I will try to refactor these codes in these days when I have time. :)