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

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

> Any chance this could be wired up to the existing buildbot or jenkins
infrastructure, rather than having another one?
Parallel to the Jenkins job we started to work on a simplified buildbot
instance, see https://reviews.llvm.org/D61848. The process of integrating
that, however, seems to be stuck. Maybe Galina and Endre could revive that
process? Also, the Jenkins job is long running job, it takes 8 hours to
complete (8cores/64GB azure vm), but it analyzes 6 C/C++ projects. The
buildbot is quick, it takes roughly 1-2 hours, but analyzes only one simple
C project.

About Jenkins in LLVM I have many infrastructural questions:
Is there a way to integrate our Jenkins job to any LLVM Jenkins cluster? I
know about http://green.lab.llvm.org/green/,  but that cluster seems to be
OSX only. We need Linux. Is there a Jenkins cluster of Linux executors we
could use? Should we somehow connect our Azure vm into that cluster as an
additional executor?

Gabor

On Tue, Nov 19, 2019 at 8:48 PM David Blaikie <dblaikie at gmail.com> wrote:

> 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/20191120/89257fa3/attachment.html>