Skip to content

Improve handling of non-reproducible crashes #42

@saelo

Description

@saelo

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:

dup2(devnull, 2);
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).

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions