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

[David Blaikie via cfe-dev]

Any chance this could be wired up to the existing buildbot or jenkins
infrastructure, rather than having another one?

(I'm not 100% sure it's better for it to all be together, but figured I'd
ask/perhaps there are reasons that've already been considered/articulated)

On Mon, Nov 18, 2019 at 9:18 AM Gábor Márton via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> 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
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20191119/3057bc4e/attachment.html>