Re: BUG #6672: Memory leaks in dumputils.c

On Fri, Jun 1, 2012 at 9:26 PM, Josh Kupershmidt <schmiddy(at)gmail(dot)com> wrote:
> On Fri, Jun 1, 2012 at 4:23 PM, Anna Zaks <zaks(dot)anna(at)gmail(dot)com> wrote:
>
>> I opened an analyzer Bugzilla report for this issue in case you 'd
>> like to follow up there:
>> http://llvm.org/bugs/show_bug.cgi?id=13010
>
> Thanks, I'll try to schedule another run tonight and post additional
> details on that ticket.
>
> On Fri, Jun 1, 2012 at 4:02 AM, Peter Geoghegan <peter(at)2ndquadrant(dot)com> wrote:
>
>> I saw a number of false positives when I ran the Clang static analyser
>> a few months ago. As I recall, I could see why the tool concluded that
>> certain lines of code may have contained errors, even though it was
>> evident to me that they actually did not. That said, it probably
>> wouldn't hurt to give it another try sometime soon.
>
> Yeah, there seems to be a lot of noise in the results, but I found
> them interesting nonetheless. I put up the HTML report at:
>  http://kupershmidt.org/pg/scan-build-2012-05-31-1/
>
> since it's way too big to mail even a tarball. It's too bad the clang
> doesn't understand our ereport(ERROR, ...) calls don't return to the
> caller, as those seem to account for a fair bit of the spurious
> warnings. I haven't seen anything which I'd call an outright bug,
> though there are e.g. non-kosher uses of malloc() which could
> certainly be improved.
>
> Hrm, I wonder if proc_exit() and ExitPostmaster() could be declared
> with __attribute__((noreturn)) , that seems like it would quiet a few
> errors.
>

Keep in mind that the analyser does not perform analyses across
translation units (files), so it will not 'see' implementation of the
custom assertion handler unless it's defined in the same file.

Cheers,
Anna.

> Josh