This is an archive of the discontinued LLVM Phabricator instance.

[libFuzzer] Fix minimizing timeouts
ClosedPublic

Authored by iii on Aug 5 2020, 1:57 PM.

Details

Summary

When one tries to minimize timeouts using -minimize_crash=1,
minimization immediately fails. The following sequence of events is
responsible for this:

[parent] SIGALRM occurs
[parent] read() returns -EINTR (or -ERESTARTSYS according to strace)
[parent] fgets() returns NULL
[parent] ExecuteCommand() closes child's stdout and returns
[child ] SIGALRM occurs
[child ] AlarmCallback() attempts to write "ALARM: ..." to stdout
[child ] Dies with SIGPIPE without calling DumpCurrentUnit()
[parent] Does not see -exact_artifact_path and exits

When minimizing, the timer in parent is not necessary, so fix by not
setting it in this case.

Diff Detail

Event Timeline

iii created this revision.Aug 5 2020, 1:57 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 5 2020, 1:57 PM
Herald added subscribers: Restricted Project, kristof.beyls. · View Herald Transcript
iii requested review of this revision.Aug 5 2020, 1:57 PM
kcc added a comment.Aug 6 2020, 10:51 AM

O, wow, thanks for catching this.
Could you please add a test (in compiler-rt/test/fuzzer) that would reliably fail currently
and reliably pass with this change?

iii updated this revision to Diff 284310.Aug 10 2020, 4:11 AM
  • Added a test.
  • Moved Alrm after Abrt in order to maintain the alphabetic order.
iii added a comment.EditedAug 10 2020, 3:02 PM

The failing test is libFuzzer :: cleanse.test, but I don't think this is due to my patch - it doesn't fail locally, and it didn't fail the last time. I wonder if build machines do parallel builds? If yes, then the following code might be the culprit:

auto TmpFilePath = TempPath("CleanseCrashInput", ".repro");
...
for (int NumAttempts = 0; NumAttempts < 5; NumAttempts++) {
    ...
    for (auto NewByte : ReplacementBytes) {
      U[Idx] = NewByte;
      WriteToFile(U, TmpFilePath);
      auto ExitCode = ExecuteCommand(Cmd);
      RemoveFile(TmpFilePath);

After the file is removed, a parallel build might be reusing its name, causing all sorts of chaos.

This revision is now accepted and ready to land.Aug 11 2020, 10:38 AM
This revision was landed with ongoing or failed builds.Aug 11 2020, 1:16 PM
This revision was automatically updated to reflect the committed changes.