* scan.coverity: improve the modeling file of git.git
@ 2014-07-20 21:44 Stefan Beller
2014-07-22 8:33 ` Jeff King
0 siblings, 1 reply; 2+ messages in thread
From: Stefan Beller @ 2014-07-20 21:44 UTC (permalink / raw)
To: peff, john, sam, GIT Mailing-list
Hi Sam, John and Jeff,
I'm writing to you, as you're listed as the
administrator of the git.git project
on scan.coverity.com
We're currently seeing lots of false positives
as the xmalloc/xrealloc function is handled not properly
by coverity. There are lots of errors "Allocation too small for type"
Quoting (starting linenumbers are code) from some xrealloc ocurrence:
95void *xrealloc(void *ptr, size_t size)
96{
97 void *ret;
98
99 memory_limit_check(size);
100 ret = realloc(ptr, size);
1. Condition "!ret", taking true branch
2. Condition "!size", taking true branch
101 if (!ret && !size)
3. buffer_alloc: "realloc(void *, size_t)" which allocates 1 bytes based on "1UL".
4. var_assign: Assigning: "ret" = storage allocated by "realloc(ptr, 1UL)".
102 ret = realloc(ptr, 1);
5. Condition "!ret", taking false branch
103 if (!ret) {
104 try_to_free_routine(size);
105 ret = realloc(ptr, size);
106 if (!ret && !size)
107 ret = realloc(ptr, 1);
108 if (!ret)
109 die("Out of memory, realloc failed");
110 }
6. return_dbuffer: Returning allocated array "ret".
111 return ret;
112}
However I have reviewed the function and I'd be pretty sure it would work as expected.
According to https://scan.coverity.com/tune we can upload a modelling file,
which will allow us to supress such false positive errors.
I believe we'd need to put in the modelling file something like:
// coverity[+alloc]
void *xrealloc(void *ptr, size_t size);
and that should do. We'd not need to modify the git.git sources,
but just add such a declaration to the modelling file.
Does anyone of you administrators want to experiment with that?
Cheers,
Stefan
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: scan.coverity: improve the modeling file of git.git
2014-07-20 21:44 scan.coverity: improve the modeling file of git.git Stefan Beller
@ 2014-07-22 8:33 ` Jeff King
0 siblings, 0 replies; 2+ messages in thread
From: Jeff King @ 2014-07-22 8:33 UTC (permalink / raw)
To: Stefan Beller; +Cc: john, sam, GIT Mailing-list
On Sun, Jul 20, 2014 at 11:44:53PM +0200, Stefan Beller wrote:
> We're currently seeing lots of false positives
> as the xmalloc/xrealloc function is handled not properly
> by coverity. There are lots of errors "Allocation too small for type"
Hmm. Actually, I think this report from coverity kind of makes sense.
If you pass zero bytes to xmalloc, like:
const char **foo = xmalloc(0);
and your system malloc returns NULL, we convert that into a single-byte
allocation, and it is the caller's responsibility not to actually
dereference it. Coverity doesn't know that, and says "wait, one byte
isn't enough to store *foo", which is right.
Most cases of this are something like:
const char **foo = xmalloc(nr * sizeof(*foo));
/* do something nr times */
What coverity _should_ be able to do is realize that we only trigger
this when "nr" is zero, and then make sure that we only dereference foo
when nr is non-zero. But I guess it's not that smart (yet).
As a fallback, we should be able to say "xrealloc is opaque; just trust
us that it will allocate the right amount", which I think is what you
are getting at with the modeling file.
> However I have reviewed the function and I'd be pretty sure it would work as expected.
> According to https://scan.coverity.com/tune we can upload a modelling file,
> which will allow us to supress such false positive errors.
> I believe we'd need to put in the modelling file something like:
>
> // coverity[+alloc]
> void *xrealloc(void *ptr, size_t size);
>
> and that should do. We'd not need to modify the git.git sources,
> but just add such a declaration to the modelling file.
I think that is how we would comment it in the source code. For the
modeling file, we would actually provide a "fake" implementation of
xmalloc that just calls malloc. I think you shouldn't generally need to
model functions which are actually in your code base (as coverity looks
across all files, not just what gets included when compiling any single
one), but I assume that a model would take precedence over the "real"
one for cases like this.
> Does anyone of you administrators want to experiment with that?
I don't think anybody is actively submitting builds to coverity. I
played with it a while ago and have meant to look again when I got more
time (as there were many false positives that I figured could be removed
with some modeling), but haven't gotten around to it.
I'm happy to upload any model file you want, or if you want to actively
work on this, I can bump you to "maintainer" status and you can fiddle
with the project settings as necessary.
-Peff
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2014-07-22 8:33 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-07-20 21:44 scan.coverity: improve the modeling file of git.git Stefan Beller
2014-07-22 8:33 ` Jeff King
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).