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

Unit TestsFailed

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.