[MASSMAIL]Coverity complains about simplehash.h's SH_STAT() - Mailing list pgsql-hackers

From Tom Lane
Subject [MASSMAIL]Coverity complains about simplehash.h's SH_STAT()
Date
Msg-id 3005248.1712538233@sss.pgh.pa.us
Whole thread Raw
Responses Re: Coverity complains about simplehash.h's SH_STAT()
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Sutou Kouhei
Date:
Subject: Re: meson: Specify -Wformat as a common warning flag for extensions
Next
From: Peter Geoghegan
Date:
Subject: Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan