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

From Tom Lane
Subject Re: Clang 3.3 Analyzer Results
Date
Msg-id 18795.1384304391@sss.pgh.pa.us
Whole thread Raw
In response to Re: Clang 3.3 Analyzer Results  (Jeffrey Walton <noloader@gmail.com>)
Responses Re: Clang 3.3 Analyzer Results  (Kevin Grittner <kgrittn@ymail.com>)
List pgsql-hackers
Jeffrey Walton <noloader@gmail.com> writes:
> On Tue, Nov 12, 2013 at 7:11 PM, Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
>> We have marked a large number of memory leak reports by Coverity in
>> initdb and other short-lived programs as false positive, on the grounds
>> that there's no point in freeing memory in a program that's about to
>> terminate anyway.  I'm not saying I agree necessarily with that POV, but
>> if we take that stance then there's similarly no point in fixing this
>> leak in the regression test code, is there?

> Ah, OK. So I would disagree here.
> Test code has to meet the same standards as production code.

No, this isn't about test code vs production, it's about not bothering
to free memory explicitly when a program is about to terminate.  Alvaro
is suggesting that the proposed addition to pg_regress.c is just a waste
of cycles.  IMO it's not that big a deal either way in this case, since
it's just one line of code that isn't going to take too long.  However,
I would push back pretty darn hard if you suggested that, say, the
server needed to explicitly free everything it'd allocated before
terminating --- the amount of bookkeeping needed for that would be
ginormous, and it would be 100% pointless.

From a testing standpoint, that means we need a way to explain to
any analysis code that we don't care about the fact that specific
allocations will still be there at termination.  This isn't all that
much different from suppressing other types of false positive, of
course.  As Alvaro and a couple of other people have mentioned, we've
gone to some effort to identify and mark false positives with Coverity.
I'm not convinced yet that clang's tools are mature enough to justify
putting in similar effort with it.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: nested hstore patch
Next
From: Michael Paquier
Date:
Subject: Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]