Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fuzzer quits without saving crash #58

Open
apx-1 opened this issue Jun 4, 2024 · 2 comments
Open

Fuzzer quits without saving crash #58

apx-1 opened this issue Jun 4, 2024 · 2 comments

Comments

@apx-1
Copy link

apx-1 commented Jun 4, 2024

I had a similar issue like #23.

When crash is detected, it tries to reproduce the crash.

// save crashes and hangs immediately when they are detected
  if (result == CRASH) {
    string crash_desc = tc->instrumentation->GetCrashName();
    
    if (crash_reproduce_retries > 0) {
        if (TryReproduceCrash(tc, sample, init_timeout, timeout) == CRASH) {
            // get a hopefully better name
            crash_desc = tc->instrumentation->GetCrashName();
        } else {
            crash_desc = "flaky_" + crash_desc;
        }
    }

If it is !tc->sampleDelivery->DeliverSample(sample), the fuzzer quits without saving the crash.

RunResult Fuzzer::TryReproduceCrash(ThreadContext* tc, Sample* sample, uint32_t init_timeout, uint32_t timeout) {
  RunResult result;

  for (int i = 0; i < crash_reproduce_retries; i++) {
    total_execs++;

    if (!tc->sampleDelivery->DeliverSample(sample)) {
      WARN("Error delivering sample, retrying with a clean target");
      tc->instrumentation->CleanTarget();
      if (!tc->sampleDelivery->DeliverSample(sample)) {
        FATAL("Repeatedly failed to deliver sample");
      }
    }

    result = tc->instrumentation->RunWithCrashAnalysis(tc->target_argc, tc->target_argv, init_timeout, timeout);
    tc->instrumentation->ClearCoverage();

    if (result == CRASH) return result;
  }

  return result;
}

I think it is better to save the crash before FATAL("Repeatedly failed to deliver sample");

@apx-1
Copy link
Author

apx-1 commented Jun 4, 2024

I've noticed multiple !tc->sampleDelivery->DeliverSample(sample) checks prior to the steps that lead to Fuzzer::TryReproduceCrash. I found several valid crashes without these checks, so it might be better to remove them from Fuzzer::TryReproduceCrash? The fuzzer often FATALs when using file delivery in ram.

@ifratric
Copy link
Collaborator

Sure, we can remove the FATAL when reproducing crashes, I just pushed 36d79fb
However, after saving the crash, the fuzzer will likely still error out because it will be unable to save the next mutated sample. I would be more interested in the root cause, why writing the sample fails for these targets.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants