From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Possible cache reference leak by removeExtObjInitPriv |
Date: | 2020-04-20 08:28:29 |
Message-ID: | 20200420.172829.2127423900576917488.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Fri, 17 Apr 2020 13:07:15 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in
> Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jürgen Purtz | 2020-04-20 08:30:20 | Re: Additional Chapter for Tutorial |
Previous Message | Dilip Kumar | 2020-04-20 08:01:55 | Re: fixing old_snapshot_threshold's time->xid mapping |