[cfe-dev] clang --analyze: how do I get more verbose diagnostics?

Jared Grubb jared.grubb at gmail.com
Mon Nov 18 19:48:20 PST 2013


On Nov 18, 2013, at 11:00, Anna Zaks <ganna at apple.com> wrote:

> 
> On Nov 17, 2013, at 9:12 PM, Tomasz Mikolajczyk <tmmikolajczyk at gmail.com> wrote:
> 
>> "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!

> (When developing checkers, this page would definitely be useful: http://clang-analyzer.llvm.org/checker_dev_manual.html.)
> 
> Anna.
>> 
>> On Mon, Nov 18, 2013 at 3:44 AM, Jared Grubb <jared.grubb at gmail.com> wrote:
>> 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
>> 
>> On Nov 14, 2013, at 9:27, Jordan Rose <jordan_rose at apple.com> wrote:
>> 
>>> 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
>>> 
>>> 
>>> On Nov 12, 2013, at 11:56 , Richard <legalize at xmission.com> wrote:
>>> 
>>>> 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?
>>>> -- 
>>>> "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
>>>>     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
>>>>         The Terminals Wiki <http://terminals.classiccmp.org>
>>>>  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>> 
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> 
>> 
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> 
>> 
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> 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/20131118/2fc48cba/attachment.html>


More information about the cfe-dev mailing list