Repository navigation
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)
| "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.
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.
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)
3 participants
Gather more metrics and print them in the fuzzer_stats report to better understand how a fuzzer behaves:
getrusageonRUSAGE_CHILDREN(the parent process needs to end and wait for the children to use theRUSAGE_CHILDRENoption).