Replies: 1 comment
-
Instability is only an issue if that start to go below 90%. The unstable edge comes from __AFL_LOOP. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I have been using the "basic" persistent mode (via
__AFL_INIT
) for fuzzing libopenmpt code for a long time, and when I first tried it out many years ago, I also tried to use the more advanced__AFL_LOOP
mechanism. My code has perfect stability with__AFL_INIT
(all code that is under my control is deterministic), but with__AFL_LOOP(10000)
the stability drops to 99.xx%. That was already the case when I tried it a few years ago. Now I decided to try it again to see if anything changed, and this is still happening.I want to gain a better understanding of why it is happening, as I am not aware of any state being shared between runs in my code. The nondeterministic
var_bytes
are all concentrated around two classes that contain lots of floating-point calculations. Even after setting the float rounding mode explicitly before each test case the instability remains. What confuses me even more is that neither are these two classes the only code that makes a lot use of floating-point calculations, nor do the functions in which thevar_bytes
are found actually contain any branches that would depend on the content of floating-point values (in one of the two classes, anyway - and the two classes don't interact with each other).So as a result, I'm still at a loss at what could be causing the stability issues. I know that the docs linked above say "If a persistent target is unstable whereas when run non-persistent is fine, then this means that the target is keeping internal state, which is bad for fuzzing. Fuzz such targets without persistent mode." - but I am pretty sure that such internal state does not exist in my code, in particular not in the functions covered by
var_bytes
. I would appreciate any help in debugging and better understanding where this instability could be coming from. I know that 99.xx% is stable enough to still find problems - but I'd rather prefer if it were 100% so that I can see when real stability issues arise.Beta Was this translation helpful? Give feedback.
All reactions