clang --analyze: how do I get more verbose diagnostics?

clang --analyze reports this problem in my code:

warning: Potential memory leak
        for (extent_vector_iter deit = disk_.provided_extents.begin();
             deit != disk_.provided_extents.end(); ++deit)
                                                   ^~
1 warning generated.

Context:
  typedef std::vector<extent_data> extent_vector;
  typedef extent_vector::const_iterator extent_vector_iter;

  extent_data has no raw pointers, only non-pointer POD types and other
  standard library classes like string and vector of string, etc.

The problem with this diagnostic is that it points to the place where
it thinks a memory leak may occur, but it doesn't provide me with a
chain of reasoning that makes me understand why it thinks this
particular chunk of code may leak memory.

Am I missing some magic flag to tell me this extra level of
information, or is that ability simply lacking?

Hi, Richard. "clang --analyze” is not intended to be a usual interface for the analyzer, merely an invocation that higher-level tools can use. The correct way to run the analyzer, even on a single file, is through the scan-build tool, which provides HTML output that shows you the full path to the purported bug. (Or through Xcode, of course, if you’re on a Mac.)

Sorry for the inconvenience,
Jordan

You can get HTML reports (which show the whole chain of reasoning) using

clang --analyze -Xclang -analyzer-output=html -o somedir ...

BR
Magnus Reftel

In article <E835CF96-B8CC-4541-B9F1-DA06B1B6895E@apple.com>,
    Jordan Rose <jordan_rose@apple.com> writes:

Hi, Richard. "clang --analyze" is not intended to be a usual interface for
the analyzer, merely an invocation that higher-level tools can use. The
correct way to run the analyzer, even on a single file, is through the
scan-build tool, which provides HTML output that shows you the full path to
the purported bug. (Or through Xcode, of course, if you're on a Mac.)

Thanks for pointing this out, Jordan. I'm away from the computer
where I have clang installed at the moment. Does the man page for
clang mention any of this where --analyze is described? I don't think
it was.

Is there a way to debug checkers and BugReporterVisitors? I’m trying to implement a visitor, but having trouble getting it to show any notes.

Based on your advice, I tried this:

$ /Users/grubber/src/llvm/tools/clang/tools/scan-build/scan-build --use-analyzer=/Users/grubber/src/llvm-build/Debug+Asserts/bin -v -v -v -enable-checker alpha.cplusplus.BlockRefCapture -enable-checker core --view clang++ -fblocks -std=c++11 blocks.cpp
sh: /Users/grubber/src/llvm-build/Debug+Asserts/bin: is a directory
scan-build: Using ‘/Users/grubber/src/llvm-build/Debug+Asserts/bin’ for static analysis
scan-build: Emitting reports for this run to ‘/var/folders/fq/4_p48fh50_72j_gt7_pfgn_40000gn/T/scan-build-2013-11-17-184203-37891-1’.
clang++ -fblocks -std=c++11 blocks.cpp
scan-build: Removing directory ‘/var/folders/fq/4_p48fh50_72j_gt7_pfgn_40000gn/T/scan-build-2013-11-17-184203-37891-1’ because it contains no reports.
scan-build: No bugs found.

But that didnt find any issue, so I’m thinking it’s not actually trying my alpha checker?

Jared

“sh: /Users/grubber/src/llvm-build/Debug+Asserts/bin: is a directory”

You mean --use-analyzer=/Users/grubber/src/llvm-build/Debug+Asserts/bin/clang++ I guess

In article <E835CF96-B8CC-4541-B9F1-DA06B1B6895E@apple.com>,
   Jordan Rose <jordan_rose@apple.com> writes:

Hi, Richard. "clang --analyze" is not intended to be a usual interface for
the analyzer, merely an invocation that higher-level tools can use. The
correct way to run the analyzer, even on a single file, is through the
scan-build tool, which provides HTML output that shows you the full path to
the purported bug. (Or through Xcode, of course, if you're on a Mac.)

Thanks for pointing this out, Jordan. I'm away from the computer
where I have clang installed at the moment. Does the man page for
clang mention any of this where --analyze is described? I don't think
it was.

scan-build and Xcode are considered to be the tools to use when you want to run the "clang static analyzer". They invoke "clang --analyze" during processing (clang --analyze is not considered to be a user-level tool).

See http://clang-analyzer.llvm.org for more info.

Anna.

The clang man page is lacking in many ways, and it certainly isn’t the definitive reference for the static analyzer. The intended documentation location is clang-analyzer.llvm.org. We probably should remove the —analyze reference from the clang man page.

“sh: /Users/grubber/src/llvm-build/Debug+Asserts/bin: is a directory”

You mean --use-analyzer=/Users/grubber/src/llvm-build/Debug+Asserts/bin/clang++ I guess

Right.

Jared,

It really depends on what you are trying to debug…

scan-build is a perl script located in clang/tools/scan-build folder. It calls clang on each file in your project asking it to perform “analyze” action. You can run it in verbose mode to see which clang commands get executed and see if your checker is passed to clang.

When debugging your checker implementation or BugReporterVisitors, you’d call clang directly with a command line similar to this: “clang -cc1 -analyze -analyzer-checker=core -analyzer-output=text”. You can add your checker after the “core” package on the command line. Also, note that the text output might be different from what you see in HTML or plist and it should only be used for debugging.

(When developing checkers, this page would definitely be useful: http://clang-analyzer.llvm.org/checker_dev_manual.html.)

Anna.

In article <FCA5A3EA-A7BA-4053-B6E2-A54704C5489C@apple.com>,
    Ted Kremenek <kremenek@apple.com> writes:

The clang man page is lacking in many ways, and it certainly isn't the
definitive reference for the static analyzer. The intended documentation
location is clang-analyzer.llvm.org. We probably should remove the
--analyze reference from the clang man page.

I would rather see the man page updated to point the interested reader
to that URL for more information!

I CAN DO THIS! :slight_smile: Should I submit a patch?

“sh: /Users/grubber/src/llvm-build/Debug+Asserts/bin: is a directory”

You mean --use-analyzer=/Users/grubber/src/llvm-build/Debug+Asserts/bin/clang++ I guess

Right.

Yes, that did work too … although your solution below is perfect.

Jared,

It really depends on what you are trying to debug…

scan-build is a perl script located in clang/tools/scan-build folder. It calls clang on each file in your project asking it to perform “analyze” action. You can run it in verbose mode to see which clang commands get executed and see if your checker is passed to clang.

When debugging your checker implementation or BugReporterVisitors, you’d call clang directly with a command line similar to this: “clang -cc1 -analyze -analyzer-checker=core -analyzer-output=text”. You can add your checker after the “core” package on the command line. Also, note that the text output might be different from what you see in HTML or plist and it should only be used for debugging.

Yes, perfect! I had googled and tried “-analyzer-output=html”, which gave me absolutely nothing. I struggled to find anything that would output the notes, but that does it. Thanks!

OK, I'm still having a hard time getting useful results from this,
even when I use scan-build.

We use SCons for our build system. When I run 'scan-build scons
<args>', my build runs for a long time and reports various warnings
from the analysis as it runs.

When the whole thing finally finishes, scan-build claims that there is
nothing to report and I'm left with a bunch of *.plist directories in
the current directory from where I invoked scan-build.

If I look in these .plist directories, there are HTML files that
contain a report of the different warnings that were reported during
the build process.

So, I'm confused.

1) Why does scan-build claim there is nothing wrong when clearly a
bunch of analysis warnings were emitted during the build process?

2) Why are these .plist directories laying around?

I would recomment starting by replacing scons, but at the very least
sure that your construct honors CC etc from environment.

Joerg

In article <20131119113333.GA5152@britannica.bec.de>,
    Joerg Sonnenberger <joerg@britannica.bec.de> writes:

> We use SCons for our build system. When I run 'scan-build scons
> <args>', my build runs for a long time and reports various warnings
> from the analysis as it runs.

I would recomment starting by replacing scons, but at the very least
sure that your construct honors CC etc from environment.

Sorry, but suggesting someone replace their build system is not
going to be taken seriously. This also runs contrary to the entire
point of scan-build.

If my build environment wasn't getting clang for compilation, then I
wouldn't be getting clang analysis diangostics in the output of the
build as I already stated was happening.

Clearly it is running as I get these .plist directories with HTML
reports in them. What I don't get is a summary report that combines
the .plist directory contents. Also, from reading the description of
scan-build, it implies that all the reports are put in a directory in
/tmp, which clearly isn't happening.

That definitely isn’t how it’s supposed to work, but…does scons clear the environment before it invokes the compiler? scan-build works by setting environment variables that are then picked up by its helper script, ccc-analyzer.

It looks like this is a known issue: http://stackoverflow.com/questions/9305356/how-can-i-make-clangs-scan-build-work-with-scons. We should add that to the site.

Jordan

In article <20131119113333.GA5152@britannica.bec.de>,
    Joerg Sonnenberger <joerg@britannica.bec.de> writes:

> > We use SCons for our build system. When I run 'scan-build scons
> > <args>', my build runs for a long time and reports various warnings
> > from the analysis as it runs.
>
> I would recomment starting by replacing scons, but at the very least
> sure that your construct honors CC etc from environment.

Sorry, but suggesting someone replace their build system is not
going to be taken seriously. This also runs contrary to the entire
point of scan-build.

Well, some of the requirements of scan-build require a certain sanity
from the invoked build system. I have had way too much fun with scons to
know that it does break all kinds of common conventions. The way scons
constructs behave by default ignores PATH for example. CCC_CC and
friensd are other possible culprits in this context.

If my build environment wasn't getting clang for compilation, then I
wouldn't be getting clang analysis diangostics in the output of the
build as I already stated was happening.

Whether you get the output somewhere and whether it is consistent with
the expectations of the tool are quite different beasts.

Joerg

In article <C62BD100-3D92-4BAB-BA3D-1032D53426A6@apple.com>,
    Jordan Rose <jordan_rose@apple.com> writes:

It looks like this is a known issue:
How can I make Clang's "scan-build" work with SCons? - Stack Overflow

ork-with-scons. We should add that to the site.

Thanks for pointing me in the right direction.