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
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 WARN the user if --quiet is 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 stderrare 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:
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:The
analyze
command should either:WARN
the user if--quiet
is added to the invocation that analysis failures will not be reasoned aboutIt should be ensured (and tested) that even in the case of
--quiet
, thestdout
andstderr
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 likereturncode.txt
.In case we can identify that the return code corresponds to a well-defined signal (such as
-11
or139
forSIGSEGV
) we could also explicitly show this:The text was updated successfully, but these errors were encountered: