afl_skia_image_filter_deserialize stability |
||
Issue description
,
Mar 5 2018
My first impression is that this is probably not a big deal as the instability seems to be caused by initialization rather than truly non-deterministic code. To test this I ran the fuzzer using AFL on 1000 files from the CF corpus. When I did this and set the number of persistent executions to 1 (ie: AFL restarts the binary after every execution) stability is reported as 100%. But when I set persistent executions to more than 1 (ie: AFL saves time by executing LLVMFuzzerTestOneInput in a loop without restarting the binary for each execution, like libFuzzer) I see 73% stability (I'm sure this would be lower if I used more of the corpus). So my guess is that initialization code is being run once and then is being reported as unstable (since the same input won't cause the code to be executed a second time). But I'm surprised this number is so high on CF. I'll take a closer look at this. kjlubick@: the persistent executions might explain why you don't see this on your infrastructure. My guess is that you don't use persistent mode.
,
Sep 24
|
||
►
Sign in to add a comment |
||
Comment 1 by infe...@chromium.org
, Mar 5 2018Owner: metzman@chromium.org