On Thu, Apr 20, 2006 at 11:04:31AM -0400, Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > On Thu, Apr 20, 2006 at 08:51:25AM -0400, Robert Treat wrote:
> >> I think Martin Oosterhout's nearby email on coverity bug reports might make a
> >> good SoC project, but should it also be added to the TODO list?
> > ...
> > In any case, after you weed out the false-positives and exclude ECPG
> > you're only talking about less than 50 issues that may need to be
> > addressed. Hardly a project that will take any amount of time.
>
> Nor one we'd be willing to wait till the summer to address, if any of
> the bugs are real.
Most of the stuff remaining is memory leaks in the src/bin directories,
and ECPG. The memory leaks are not important there (initdb leaks like a
sieve in many places).
About the only thing in the backend I found interesting was this:
src/backend/utils/hash/dynahash.c function hash_create
The numbers are line numbers. Somewhat squished version, hope I didn't
miss anything.
185 if( flags & HASH_SHARED_MEM) {
193 hashp->hcxt = NULL;
197 if (flags & HASH_ATTACH)
198 return hashp;
199 }
256 if (!init_htab(hashp, nelem))
257 {
258 hash_destroy(hashp);
hash_destroy dereferences hashp->hcxt. I don't see anything in
init_htab that special-cases shared memory hashes. The only way this
could be avoided is if HASH_SHARED_MEM was always combined with
HASH_ATTACH. But if so, why the test?
The only other thing we could do, if we were prepare to annotate the
source, is maybe teach it about our locking stuff and have it check
that. But I don't think that's suitable for mainline, more someone's
private tree...
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
