Adding statistic metrics: peak_rss_mb and slowest_exec_ms #15
Conversation
…on stops programmatically before calling waitpid
Probably worth mentioning in the commit that these stats are reported by libFuzzer |
PR #15 added new statistics outputed to the out/fuzzer_stats file. Add tests for it. - create a .travis/ directory in which we can put helper scripts for travis - create .travis/check_fuzzer_stats.sh to parse out/fuzzer_stats and check for expected key:value pairs. - run several jobs to test for different environment variables ( AFL_EXIT_WHEN_DONE, AFL_BENCH_JUST_ONE, AFL_BENCH_UNTIL_CRASH, and manual stopping)
@@ -3440,7 +3449,8 @@ static void write_stats_file(double bitmap_cvg, double stability, double eps) { | |||
"afl_banner : %s\n" | |||
"afl_version : " VERSION "\n" | |||
"target_mode : %s%s%s%s%s%s%s\n" | |||
"command_line : %s\n", | |||
"command_line : %s\n" | |||
"slowest_exec_ms : %llu\n", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we naming/making this slowest_exec_ms
instead of libFuzzer's slowest_unit_time_sec
because the other AFL time stats are reported in ms and because AFL's timeout is usually < 1 second?
Maybe this should be named slowest_exec
to be consistent with exec_timeout?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know that libFuzzer measures slow units in seconds. But I think that since we gather the times in ms granularity (even μs) it's better to keep ms, because seconds seem a bit too coarse in a fuzzing context.
Talking about the name, if we decide to keep it in ms, I think it's better to mention it so that people don't get confused. I don't have an opinion for unit
or exec
.
Can we continue to discuss this is #23 ?
Probably worth documenting these stats in docs/status_screen.txt like the other stats. |
…oc for new stats. (#23)
Gather more metrics and print them in the fuzzer_stats report to better understand how a fuzzer behaves:
getrusage
onRUSAGE_CHILDREN
(the parent process needs to end and wait for the children to use theRUSAGE_CHILDREN
option).