As with any fuzzer, Fuzzilli can trigger crashes that do not reproduce later on. There can be various reasons for that, e.g. memory pressure of the system during the time of the crash or simply non-deterministic behaviour of the target. As JavaScript engines are quite complex, it is expected that there will be non-reproducible crashes during fuzzing.
It would, however, be nice to have some more information about how a sample originally crashed so root-causing of non-reproducible crashes becomes easier/possible. This could e.g. be done by adding a commandline flag that, when enabled, causes Fuzzilli to record stdout + stderr of the target during fuzzing and include that in the crashing testcases. That way, it should at least be somewhat clear how the sample originally crashed.
There could also be a bug in Fuzzilli that causes it to incorrectly treat some files as crashes under some circumstances. One approach to debug this would be to comment out this line:
and thus log stderr of the target during fuzzing. That should show whether the target actually crashed and roughly how it crashed (e.g. with an assertion failure).
As with any fuzzer, Fuzzilli can trigger crashes that do not reproduce later on. There can be various reasons for that, e.g. memory pressure of the system during the time of the crash or simply non-deterministic behaviour of the target. As JavaScript engines are quite complex, it is expected that there will be non-reproducible crashes during fuzzing.
It would, however, be nice to have some more information about how a sample originally crashed so root-causing of non-reproducible crashes becomes easier/possible. This could e.g. be done by adding a commandline flag that, when enabled, causes Fuzzilli to record stdout + stderr of the target during fuzzing and include that in the crashing testcases. That way, it should at least be somewhat clear how the sample originally crashed.
There could also be a bug in Fuzzilli that causes it to incorrectly treat some files as crashes under some circumstances. One approach to debug this would be to comment out this line:
fuzzilli/Sources/libreprl/libreprl.c
Line 106 in 2e7c967