Re: Clang 3.3 Analyzer Results - Mailing list pgsql-hackers

From Jeffrey Walton
Subject Re: Clang 3.3 Analyzer Results
Date
Msg-id CAH8yC8nCR=fjBRVpCdJBDktBOBMNMzSwm6aCST8YtGyuMnJ4PA@mail.gmail.com
Whole thread Raw
In response to Re: Clang 3.3 Analyzer Results  (Kevin Grittner <kgrittn@ymail.com>)
List pgsql-hackers
On Mon, Nov 11, 2013 at 6:01 PM, Kevin Grittner <kgrittn@ymail.com> wrote:
> Peter Geoghegan <pg@heroku.com> wrote:
>> Kevin Grittner <kgrittn@ymail.com> wrote:
>>
>>> I'm currently capturing a text version of all the warnings from
>>> this.  Will gzip and post when it finishes.  It's generating a lot
>>> of warnings; I have no idea how many are PostgreSQL problems and
>>> how many are false positives; will just post the whole set FWIW.  I
>>> am using the 3.4 development nightly snapshot with these commands:
>>
>> When I tried out scan-build a while ago, the results were kind of
>> disappointing - there were lots of false positives. Clearly the tool
>> was inferior to Coverity at that time. I'd be interested to see if
>> there has been much improvement since.
>
> Perhaps it will be of some value in terms of filing additional bug
> reports with clang if it proves to have so many false positives
> that it has little value in evaluating PostgreSQL code.
>
> It does seem hard to believe that clang tools would find as enough
> problems that were missed by Coverity and Valgrind to account for
> all the warnings that are scrolling by; but it looks like it has
> pointed out at least *one* problem that's worth fixing.
>
> Ah, it finished.  Results attached; I haven't had time to review
> them yet.
The sanitizers are *bad ass*, especially the undefined behavior
checker (UBC or UBSan). There are no false positives when using it.

UBSan was based upon Peng and Regher's Integer Overflow Checker (we
used IOC before Clang 3.3 because Clang prior did not have checkers).
See http://embed.cs.utah.edu/ioc/ for details.

I've used the checkers to find a number of issues in libraries during
acceptance/integration testing, including Botan, Crypto++, libevent,
libnetcpp, OpenSSL and Squid. Some libraries were so bad it was more
like "Rejection Testing" (those have not been named).

UBSan is the tool of choice when your stuff does not work after
compiling with Intel's ICC. ICC generates the fastest code I have
seen, and it is ruthless about dropping undefined behavior in an
effort to speed up execution.

By the way, that -fwrapv is a crutch for illegal programs. It would be
wise to fix the problems rather than masking them with -fwrapv. You
can use UBSan to help ferret out the problems that -fwrapv hides. See
Ian Lance Taylor's blog for details:
http://www.airs.com/blog/archives/120.

Jeff



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Fast insertion indexes: why no developments
Next
From: Jeff Janes
Date:
Subject: Re: Fast insertion indexes: why no developments