From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | michael(at)paquier(dot)xyz |
Cc: | kaegoorn48(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17184: When using openssl, the memory of a static variable is not freed in libpq |
Date: | 2021-09-13 02:59:18 |
Message-ID: | 20210913.115918.81531535479754361.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
At Fri, 10 Sep 2021 11:12:21 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in
> On Thu, Sep 09, 2021 at 08:32:58AM +0300, Alexander Dzuba wrote:
> > I know that this is not the real leak, but memcheck analysis shows that the
> > memory was not released. Because of this, CI tests fail and deploy is
> > blocked.
>
> Perhaps there is room for improvement in valgrind.supp then?
If I specified '--leak-check=full --show-leak-kinds=reachable' (or
'all') for psql, I see many other complaints for the other than the
my_BIO_s_socket. And I saw two errors in my_BIO_s_socket.
So even if I tried to silence valgrind about the errors by inserting
something like the below into the file, still there are many other
errors.
{
<insert_a_suppression_name_here>
Memcheck:Leak
match-leak-kinds: reachable
fun:malloc
...
fun:initialize_SSL
}
The following beats out all reachable errors come from malloc, realloc
and calloc (and any other *alloc's:p) but I don't think this is what
we want here...
{
<insert_a_suppression_name_here>
Memcheck:Leak
match-leak-kinds: reachable
fun:*alloc
}
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-09-13 04:37:21 | Re: BUG #17186: In connect.c, the lock connections_mutex is not correctly released(Line 463) at the return(Line 522) |
Previous Message | Andrew Dunstan | 2021-09-12 18:41:23 | Re: pg_upgrade test for binary compatibility of core data types |