You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a program instrumented by RuntimeAssistedMutator crashes, we avoid calling
processCrash() on it immediately. This is because the boilerplate code added
during instrumentation makes such crashes difficult to minimize
(see, e.g., https://g-issues.chromium.org/issues/488963988?pli=1&authuser=0).
Instead, we follow this procedure:
1. Always log the crash of the instrumented program.
2. Check if the process()'d version of the instrumented program also crashes.
3. If yes, we call processCrash() on that program instead, as its more straightforward to minimize.
Bug: 488963988
Change-Id: Iffefc9435f4ef31a3fbf798d374a04f9f1fc115a
Reviewed-on: https://chrome-internal-review.googlesource.com/c/v8/fuzzilli/+/9129498
Reviewed-by: Matthias Liedtke <mliedtke@google.com>
Commit-Queue: Leon Bettscheider <bettscheider@google.com>
// We need to cache these because they're invalidated the next time we call execute().
95
+
letoldStdout= execution.stdout
96
+
letoldStderr= execution.stderr
97
+
letoldFuzzout= execution.fuzzout
93
98
switch execution.outcome {
94
99
case.failed(_):
95
100
// We generally do not expect the instrumentation code itself to cause runtime exceptions. Even if it performs new actions those should be guarded with try-catch.
@@ -109,8 +114,31 @@ public class RuntimeAssistedMutator: Mutator {
109
114
// In this case we still try to process the instrumentation output (if any) and produce the final, uninstrumented program
110
115
// so that we obtain reliable testcase for crashes due to (1). However, to not loose crashes due to (2), we also
111
116
// report the instrumented program as crashing here. We may therefore end up with two crashes from one mutation.
0 commit comments