[cfe-dev] Clang Static Analyzer without scan-build

Wed Jul 31 16:39:58 PDT 2013

From: Anna Zaks [mailto:ganna at apple.com] 
Sent: Wednesday, July 31, 2013 5:05 PM
To: Aditya Kumar
Cc: Manuel Klimek; clang-dev Developers; Michele Galante
Subject: Re: [cfe-dev] Clang Static Analyzer without scan-build

On Jul 31, 2013, at 2:53 PM, Aditya Kumar <hiraditya at codeaurora.org> wrote:

From: Anna Zaks [ <mailto:ganna at apple.com> mailto:ganna at apple.com] 
Sent: Wednesday, July 31, 2013 3:50 PM
To: Aditya Kumar
Cc: Manuel Klimek; clang-dev Developers; Michele Galante
Subject: Re: [cfe-dev] Clang Static Analyzer without scan-build

On Jul 31, 2013, at 12:13 PM, Aditya Kumar <
<mailto:hiraditya at codeaurora.org> hiraditya at codeaurora.org> wrote:

I have a preliminary working version of my patch and I ran it through our
test framework (>100 MLOC), and it has worked fine.

To generate the summarized report (index.html) I copied some portions of
scan-build and generated the summary.

I'm planning to write some post-processing program that parses the
report-*.html files and stores them in a database.

Will that be useful?

This depends on the workflow you have in mind. What reports the database
will contain: ex, the results of the latest build or results of every
build... 

I think the database might have limited usefulness if you are doing partial
builds, at least you don't really know which set of bugs you are looking at.

A useful workflow includes running the analyzer as part of continuous
integration and storing results of every build. In that scenario, it is
useful to only show / highlight the diff of issues or only new issues that
the analyzer produces on the latest build. We do not have a very good
infrastructure for this, but the first step would be to look at
utils/analyzer/CmpRuns.py script and see if it could be useful for you.

Thanks for telling me about utils/analyzer/CmpRuns.py.

By the way, I am totally in favor of having a stand-alone tool like
scan-build which makes it easy to run static analyzer separately as a part
of

nightly/weekly builds or by a group of people specially assigned to track
down bugs in a software infrastructure. The idea of storing
report-statistics in a database could be a useful addition to standalone
tools.

I thought the main issue for you was that scan-build does not support your
build system, so you would not be able to use it as is regardless.

(I just want to reiterate that I think that improving scan-build/building a
better version of it is the right approach as this is currently considered
the gateway for all analyzer users.)

So there are two problems.

1.       One software infrastructure which has scons build-system cannot be
analyzed with scan-build for now. This is in-fact a general problem with
scan-build or any other static analysis enterprise tool that build-system
integration is non-trivial. For that I have tried to implement
--compile-and-analyze flag. Using this facility, I was able to run clang
static analyzer on all programs/test-infrastructure available to us without
having to worry about different kinds of build system. What I'm trying to
say is we should also have facility to compile-and-analyze within the
compiler as well. This will help developers track down potential bugs as
quickly as possible. I do not want to touch scan-build because it is written
in Perl. Initially I copied some portions of it to generate summarized
report, but now I have a C++ implementation which parses all the
report-*.html files and generates a summary. I can put my patch up for
review if it can be helpful.

2.       In general I would like to improve/add support for
single-entry-point-based static analysis tool. I thought that a facility to
store reports at regular intervals (using some database etc.), will be a
small (but useful) addition in this direction.

Currently, what I have implemented is the following:

1.       compile the programs with a flag e.g., (clang++
--compile-and-analyze <path/to/report-dir> -c test.cpp). This stores all the
report-*.html files in report-dir.

Also, I have created a post-processing program which does the following:

1.       parse the report-*.html file and generate index.html. Ensure
uniqueness of each report by comparing the sha1 keys (I'm using the linux
system call to compute the sha1 keys for now).

Uniqueing reports using sha1 of the html file is not robust. Consider what
happens when someone adds a line of code to the file containing the report
somewhere before the report location.

Yes, in that case the sha1 will change, but even scan-build follows the same
approach. I'll try to find an alternative solution. Thanks for pointing this
out.

2.       populate the table in the database (mysql) with same details. To
ensure uniqueness of details I store the sha1 key of report-*.html files
along with the bug-details corresponding to each report.

Note, when running the analyzer as part of the compilation, one issue you'll
have to worry about is the __clang_analyzer__ macro, which is only defined
when you run the analyzer and not the compiler.

So the way I have defined the action-pipeline is:

0: input, "test.cpp", c++

1: analyzer, {0}, plist

2: input, "test.cpp", c++

3: preprocessor, {2}, c++-cpp-output

4: compiler, {3}, assembler

5: assembler, {4}, object

  6: linker, {5}, image

I think, this way the frontend should define the __clang_analyzer__ during
analysis and not during the compilation.

You probably want to compile before the analysis. The analyzer generally
assumes that it runs on code that compiles without errors. (This is also the
workflow of scan-build.)

That seems to be a better idea. Thanks for the suggestion.

-Aditya

Anna.

From: Manuel Klimek [ <mailto:klimek at google.com> mailto:klimek at google.com] 
Sent: Wednesday, July 31, 2013 1:15 PM
To: Anna Zaks
Cc: Aditya Kumar; clang-dev Developers; Michele Galante
Subject: Re: [cfe-dev] Clang Static Analyzer without scan-build

On Wed, Jul 31, 2013 at 8:07 PM, Anna Zaks < <mailto:ganna at apple.com>
ganna at apple.com> wrote:

On Jul 30, 2013, at 2:37 PM, Aditya Kumar <
<mailto:hiraditya at codeaurora.org> hiraditya at codeaurora.org> wrote:

I was looking at the same problem and planning to work on it.

What I'm planning to do is having a compiler flag which enables a user to
perform compilation as well as static analysis at the same time,

and make relevant changes in the clang driver to build a set of 'Actions' in
the pipeline such that static analysis and compilation takes place
simultaneously.

This will have an overhead on the overall compilation time which is often
not the desirable thing. But there is an advantage that this flag can be
incorporated in the build-system of software.

Since the build systems are really good at tracking the files which have
changed and compiling only the minimal set of required files,

the overall turnaround time of static analysis will be very small and user
can afford to run static analyzer with every build.

Have you looked at how scan-build currently works? It does compile and
analyze the source files (clang is called twice). It is also driven by the
build system, so we are not reanalyzing files that the build system would
not recompile.

The main advantage of keeping the scan-build-like interface is that, in the
future, we plan to extend the analyzer to perform cross-file(translation
unit) analysis. This is why we encourage the use of a single entry point
(scan-build) when analyzing a project.

Said that, the current implementation of scan-build is hacky and could be
improved (see  <http://clang-analyzer.llvm.org/open_projects.html>
http://clang-analyzer.llvm.org/open_projects.html).

For what it's worth, I think the way to do large scale static analysis is to
run over each TU in isolation, and output all the information needed to do
the global analysis. Then, run the global analysis as a post-processing
step, after sharding the information from that first step into
parallelizable pieces.

Note that I'm not trying to contradict what you said :) Just wanted to throw
in some experience. We are currently starting to run the analyzer on our
internal code base (see Pavel's work) based on the Tooling/ stuff
(clang-check has grown a --analyze flag) and would be very interested in
having a system that allows full codebase analysis and still works on
~100MLOC codebases... ;)

Cheers,

/Manuel

Cheers,

Anna.

I wanted some feedback if this is a good idea or not.

-Aditya

_______________________________________________
cfe-dev mailing list
 <mailto:cfe-dev at cs.uiuc.edu> cfe-dev at cs.uiuc.edu
 <http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
 <mailto:cfe-dev at cs.uiuc.edu> cfe-dev at cs.uiuc.edu
 <http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130731/6e203230/attachment.html>