[cfe-dev] [CrossTU] [CTU] Status of Cross Translation Unit Static Analysis, and a new build server

[Gábor Márton via cfe-dev]

Dear Clang Community,


TLDR; I'd like to encourage you to experiment with CTU static analysis
because it has evolved a lot this year! Usage documentation
<https://clang.llvm.org/docs/analyzer/user-docs/CrossTranslationUnit.html>
is available online.



This year, we have landed several ASTImporter patches that made it possible
to analyze even C++11/14 projects with reasonable stability. I can
confidently assure you that the upstream master of llvm/llvm-project is as
stable as our downstream fork. We've made enormous efforts to properly
implement the error handling of ASTImporter and this way we could
dramatically improve the stability of CTU. We do have a few more patches
<https://github.com/Ericsson/clang/projects/2> that we still want to land
in the future, but they are not error handling related. From Clang version
10, we no longer plan to maintain our CTU downstream fork.


We have set up a publicly available Jenkins build server
<http://codechecker-buildbot.eastus.cloudapp.azure.com:8080/job/ctu_pipeline_clang-master-monorepo/>
that continuously analyzes the following C and C++ projects:

- Tmux (C)

- Curl (C)

- Redis (C)

- Xerces (C++14)

- Bitcoin (C++11)

- Protobuf (C++11/C++14)

CTU analysis results are compared to non-CTU results
<http://codechecker-buildbot.eastus.cloudapp.azure.com:8080/job/ctu_pipeline_clang-master-monorepo/CTU_20results_20on_20open_20projects_20_28C_29/>,
both for C projects and C++ projects. CTU always results in more findings,
and the false-positive/true-positive ratio remains roughly the same [1]. We
are monitoring the analysis job, and if an assertion/crash happens then we
are going to get in touch with the author of the commit that plausibly
caused the error. We also have a buildbot patch
<https://reviews.llvm.org/D61848> in Phabricator which is ought to analyse
only one simple C project (Tmux). We decided to install  Jenkins because of
ownership and flexibility. The buildbot code is pretty convoluted and
review and communication are very slow. The buildbot also uses CodeChecker
as a dependency, changes to its workflow requires changes in the buildbot
configuration as well.


Notes:

Please note that our primary target for CTU is Linux, and we encourage
everybody
to use CodeChecker <https://github.com/Ericsson/codechecker> for CTU
(scan-build is no longer supported *by CTU developers*). Projects that use
templates heavily may expect an increase in analysis time. Also note that
CTU can be very memory consuming, e.g. in case of the analysis run on LLVM
code we've seen 10GB of resident memory usage for one process. Thus, it may
be useful to set a maximum limit for the loaded ASTUnits (e.g.
-analyzer-config ctu-import-threshold=8, with CodeChecker you need to edit
an saargs file
<https://github.com/Ericsson/codechecker/blob/master/docs/analyzer/checker_and_analyzer_configuration.md>
).


[1] 2017 EuroLLVM Developers’ Meeting: G. Horvath “Cross Translational Unit
Analysis in Clang ...”


Cheers,

Gabor Marton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20191118/b55b6666/attachment.html>