Subject: Re: Periodic Coverity Scan

Re: Periodic Coverity Scan

From: Jakub Hrozek <jhrozek_at_redhat.com>
Date: Thu, 18 Sep 2014 19:17:51 +0200

On Thu, Sep 18, 2014 at 12:13:36AM +0200, Daniel Stenberg wrote:
> On Wed, 17 Sep 2014, Jakub Hrozek wrote:
>
> >FWIW, we scan all packages in RHEL with Coverity, but mostly look at diffs
> >between versions -- which already found some bugs. I'm not sure if anyone
> >did a full review of all the messages Coverity would spit out..
>
> Oh, this made me realize my daily clang-analyzer job wasn't actually running
> on c-ares lately but I've activated it again now and its reports can be seen
> here:
>
> http://c-ares.haxx.se/scans/

cool!

In general my experience is that Coverity and clang sometimes find
different issues, so it's good to run both.

>
> It looks like we have small issues to work on.

My take:

1) Dead store Dead increment ares_init.c:1398
This seems like a false positive. I wonder if clang would
be happier if we moved "lenv *= 2;" after the realloc check? But that
would make the code less readable in my opinion.

2) Memory Error Memory leak ares_init.c:269
Seems legit. See the attached patch.

3) Memory Error Memory leak ahost.c:92
Looks legit if someone specified -s twice (does getopt allow that at
all?) But tbh I don't care about memleaks in CLI tools too much.

4) Memory Error Memory leak ares__read_line.c:64
Looks legit. At least here on a recent Fedora, the realloc man page
says:
"""
If realloc() fails the original block is left untouched; it
is not freed or moved.
"""
Kindly see the attached patch.

5) Memory Error Memory leak ares_init.c:269
We already saw that.

6) Memory Error Memory leak acountry.c:580
CLI tool :-)

7) Memory Error Memory leak ares_init.c:1623
Looks like a legit leak to me.

8) Memory Error Memory leak ares_init.c:269
We already saw that.

9) Memory Error Memory leak ares_init.c:1564
I think the core is good as-is. the servers and nserv variables are
provided by external caller and might already contain some data, so I
don't think we should attempt a cleanup on failure

Received on 2014-09-18