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