clusterfuzz icon indicating copy to clipboard operation
clusterfuzz copied to clipboard

Missing CRASH_SIGNATURE config causes bad builds

Open mi-ac opened this issue 2 years ago • 2 comments

https://github.com/google/clusterfuzz/search?q=CRASH_SIGNATURE seems to be used to determine if a build crashed in the bad-build check: https://github.com/google/clusterfuzz/blob/2ca20d6b0d8e4c7a7da4e73403e5b1579cbacd42/src/clusterfuzz/_internal/bot/testcase_manager.py#L1157

This value doesn't seem to be set anywhere? I looked if it's set on some job definitions, but couldn't find any. Like this, any return code non-zero would be interpreted as bad build, which might have happened here: https://crbug.com/1421669

mi-ac avatar Mar 06 '23 09:03 mi-ac

Yes, that's indeed the intended behaviour. CRASH_SIGNATURE can be set at a job level but is completely optional. Do you have a proposal for improving the crash detection here?

oliverchang avatar Mar 16 '23 08:03 oliverchang

My expectation was that the bad-build check and general crash checks behave equally. When checking for a crash in normal fuzzing test cases, the crash-analysis infrastructure is used (a non-zero return code is irrelevant). Why isn't that same logic used in the bad-build check?

I guess the assumption was made that when using an empty test file, like in bad-build check, a non-zero return code might be a good-enough proxy for a crash. This doesn't take into account though that some flags (e.g. in V8 case the --throws flag) might just cause a non-zero return code without crashing.

We could work around this in V8-side code, but this doesn't fix the bad-build check in old code, which IIUC is done when starting to bisect. Another work-around I assume is to skip bad-build checks via env var?

mi-ac avatar Mar 16 '23 11:03 mi-ac