Explanation as to why unreachable code slows down fuzzing

[maflcko]

See https://github.com/google/fuzzing/blob/master/docs/good-fuzz-target.md#unreachable-code

Is there an explanation available as to why it slows down fuzzing? In our experiments (with libFuzzer) we couldn't find any evidence to support this conclusion.

[inferno-chromium]

See https://github.com/google/fuzzing/blob/master/docs/good-fuzz-target.md#unreachable-code

Is there an explanation available as to why it slows down fuzzing? In our experiments (with libFuzzer) we couldn't find any evidence to support this conclusion.

@kcc - i think you wrote that recommendation, thoughts on this?

[maflcko]

Maybe fuzz engines that try to determine all reachable edges before starting the process might be slowed down by that? Not sure if any modern engine does that.

[eugenis]

AFAIK that's because coverage is stored as a byte map, which makes recording it faster, but then finding the difference is O(code size).

…

On Sat, May 8, 2021 at 1:54 AM MarcoFalke ***@***.***> wrote: Maybe fuzz engines that try to determine all reachable edges before starting the process might be slowed down by that? Not sure if any modern engine does that. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#94 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADG4STLYWYE3I2HIVMW32DTMT33XANCNFSM44JP444Q> .