-
Notifications
You must be signed in to change notification settings - Fork 440
Description
Currently, it can be non-trivial to gather why an analysis failed or crashed, especially if no outputs are provided because the --quiet flag is present in the invocation. CodeChecker may only print something as useless as follows:
Analyzing blablabla.cpp with perkele failed!
The analyze command should either:
- explicitly
WARNthe user if--quietis added to the invocation that analysis failures will not be reasoned about - or (and this is what I would prefer) either the first time (or every time?) an analysis failed, the same message should be printed
It should be ensured (and tested) that even in the case of --quiet, the stdout and stderr are captured and added to the failed ZIP. Only the command-line output should be quieted.
Failed analyses should also mention somewhere (either directly or at the bottom of the output) that the "failed ZIPs" exist and their location. Currently, it is not a widely-known fact.
In addition, we should be making some educated guesses about the analysis failure irrespective of the --quiet command. The return value of the analyser binary should be present in the log output. Currently, this can only be gathered following a successful opening of the failed ZIP (which means that if the failed ZIPs are not retained, e.g., in a CI system, this is no longer possible!) and its embedded file like returncode.txt.
Analyzing blablabla.cpp with perkele failed! (return code: 42)
In case we can identify that the return code corresponds to a well-defined signal (such as -11 or 139 for SIGSEGV) we could also explicitly show this:
Analyzing blablabla.cpp with perkele failed! (Return code: 139, SIGSEGV - Segmentation fault.)