Re: Clang 3.3 Analyzer Results

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: noloader(at)gmail(dot)com
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Clang 3.3 Analyzer Results
Date: 2013-11-13 00:59:51
Message-ID: 18795.1384304391@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Jeffrey Walton <noloader(at)gmail(dot)com> writes:
> On Tue, Nov 12, 2013 at 7:11 PM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jayadevan 2013-11-13 03:09:22 Re: Theory question
Previous Message Jeffrey Walton 2013-11-13 00:21:00 Re: Clang 3.3 Analyzer Results

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-11-13 01:29:49 Re: MVCC snapshot timing
Previous Message Andrew Dunstan 2013-11-13 00:37:54 Re: nested hstore patch