Thread: [MASSMAIL]Coverity complains about simplehash.h's SH_STAT()

[MASSMAIL]Coverity complains about simplehash.h's SH_STAT()

From
Tom Lane
Date:
Today's Coverity run produced this:

/srv/coverity/git/pgsql-git/postgresql/src/include/lib/simplehash.h: 1138 in bh_nodeidx_stat()
1132             avg_collisions = 0;
1133         }
1134
1135         sh_log("size: " UINT64_FORMAT ", members: %u, filled: %f, total chain: %u, max chain: %u, avg chain: %f,
total_collisions:%u, max_collisions: %u, avg_collisions: %f", 
1136                tb->size, tb->members, fillfactor, total_chain_length, max_chain_length, avg_chain_length,
1137                total_collisions, max_collisions, avg_collisions);
>>>     CID 1596268:  Resource leaks  (RESOURCE_LEAK)
>>>     Variable "collisions" going out of scope leaks the storage it points to.
1138     }
1139
1140     #endif                            /* SH_DEFINE */

I have no idea why we didn't see this warning before --- but AFAICS
it's quite right, and it looks like a nontrivial amount of memory
could be at stake:

    uint32       *collisions = (uint32 *) palloc0(tb->size * sizeof(uint32));

I realize this function is only debug support, but wouldn't it
be appropriate to pfree(collisions) before exiting?

            regards, tom lane



Re: Coverity complains about simplehash.h's SH_STAT()

From
Andres Freund
Date:
Hi,

On 2024-04-07 21:03:53 -0400, Tom Lane wrote:
> Today's Coverity run produced this:
> 
> /srv/coverity/git/pgsql-git/postgresql/src/include/lib/simplehash.h: 1138 in bh_nodeidx_stat()
> 1132             avg_collisions = 0;
> 1133         }
> 1134     
> 1135         sh_log("size: " UINT64_FORMAT ", members: %u, filled: %f, total chain: %u, max chain: %u, avg chain: %f,
total_collisions:%u, max_collisions: %u, avg_collisions: %f",
 
> 1136                tb->size, tb->members, fillfactor, total_chain_length, max_chain_length, avg_chain_length,
> 1137                total_collisions, max_collisions, avg_collisions);
> >>>     CID 1596268:  Resource leaks  (RESOURCE_LEAK)
> >>>     Variable "collisions" going out of scope leaks the storage it points to.
> 1138     }
> 1139     
> 1140     #endif                            /* SH_DEFINE */
> 
> I have no idea why we didn't see this warning before --- but AFAICS
> it's quite right, and it looks like a nontrivial amount of memory
> could be at stake:
> 
>     uint32       *collisions = (uint32 *) palloc0(tb->size * sizeof(uint32));
> 
> I realize this function is only debug support, but wouldn't it
> be appropriate to pfree(collisions) before exiting?

It indeed looks like that memory should be freed. Very odd that coverity
started to complain about that just now.  If coverity had started to complain
after da41d71070d, I'd understand, but that was ~5 years ago.

I can't see a way it could hurt in the back branches, so I'm inclined to
backpatch the pfree?

Greetings,

Andres Freund



Re: Coverity complains about simplehash.h's SH_STAT()

From
Tom Lane
Date:
Andres Freund <andres@anarazel.de> writes:
> On 2024-04-07 21:03:53 -0400, Tom Lane wrote:
>> I realize this function is only debug support, but wouldn't it
>> be appropriate to pfree(collisions) before exiting?

> It indeed looks like that memory should be freed. Very odd that coverity
> started to complain about that just now.  If coverity had started to complain
> after da41d71070d, I'd understand, but that was ~5 years ago.

If we recently added a new simplehash caller, Coverity might see that
as a new bug.  Still doesn't explain why nothing about the old callers.
We might have over-hastily dismissed such warnings as uninteresting,
perhaps.

> I can't see a way it could hurt in the back branches, so I'm inclined to
> backpatch the pfree?

+1

            regards, tom lane



Re: Coverity complains about simplehash.h's SH_STAT()

From
Andres Freund
Date:
On 2024-04-07 21:41:23 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I can't see a way it could hurt in the back branches, so I'm inclined to
> > backpatch the pfree?
> 
> +1

Done