You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think this is likely something we cannot resolve due to the way coverage is collected.
Probably, when import numpy is executed then various functions in the numpy module tree will be called, meaning numpy code other than def declarations will be called triggering the actual logic of the functions.
One way we could solve this is by making it such that code coverage collection begins only right before fuzzing launches, rather than, e.g. before all imports. However, this won't be perfect as well since we can still have imports triggered by the target code, although this will be done much more rarely.
Another option is to collect code coverage of the fuzzer but without any actual fuzzing and then subtract the code coverage found with a run of code coverage where the fuzzing is actually run. This way we could remove any code coverage gained from non-fuzzing code.
Another option is to make it possible for projects to add environment variables specifying which paths should be included in the code coverage reports.
Where
numpy
is imported into afuzz.py
file it's getting included in the reachability and coverage numbersA couple of examples
For toml I tried setting
export PYFUZZPACKAGE=$SRC/toml/toml
which fixed just analysing thetoml
functions but breaks the reachability analysis.The text was updated successfully, but these errors were encountered: