Possible cache reference leak by removeExtObjInitPriv

Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:

Recently a cache reference leak was reported then fixed [1].
I happened to notice a similar possible leakage in
removeEtObjInitPriv. I haven't found a way to reach the code, but can
be forcibly caused by tweaking the condition.
Please find the attached.

Ugh. recordExtObjInitPriv has the same problem.

I wonder whether there is any way to teach Coverity, or some other
static analyzer, to look for code paths that leak cache refcounts.
It seems isomorphic to detecting memory leaks, which Coverity is
reasonably good at.

regards, tom lane

At Fri, 17 Apr 2020 13:07:15 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in

Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:

Recently a cache reference leak was reported then fixed [1].
I happened to notice a similar possible leakage in
removeEtObjInitPriv. I haven't found a way to reach the code, but can
be forcibly caused by tweaking the condition.
Please find the attached.

Ugh. recordExtObjInitPriv has the same problem.

Thanks for commit it.

I wonder whether there is any way to teach Coverity, or some other
static analyzer, to look for code paths that leak cache refcounts.
It seems isomorphic to detecting memory leaks, which Coverity is
reasonably good at.

Indeed.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center