On Fri, May 29, 2020 at 02:37:29PM +0200, Matthias Apitz wrote:
> We're getting to the finish line in the port of our servers to
> PostgreSQL 11.4. and started valgrind'ing the code, as the PostgreSQL is
> new in the servers. Of course we have our own homework to do, but there
> are also complaints of valgrind pointing to the lib/libecpg.so.6.11, for
> example:
>
> ==9773== 9 bytes in 1 blocks are still reachable in loss record 3 of 52
> ==9773== at 0x4C2E2E3: malloc (vg_replace_malloc.c:299)
> ==9773== by 0x1439F749: strdup (in /lib64/libc-2.26.so)
> ==9773== by 0x146DF448: ecpg_strdup (in /usr/local/sisis-pap/pgsql/lib/libecpg.so.6.11)
> ==9773== by 0x146E048E: ECPGconnect (in /usr/local/sisis-pap/pgsql/lib/libecpg.so.6.11)
> ==9773== by 0xB03E846: DB_opdbP (dbcall.pgc:794)
> ==9773== by 0xB03DFDB: DB_opdb (dbcall.pgc:556)
> ==9773== by 0x5CC22F2: EC_General::OpenDatabase(_SQL_EXCL) (eC_general.C:121)
> ==9773== by 0x40AEB8: SlnpInitDaemon (ACQDaemon.C:644)
> ==9773== by 0x40A878: main (ACQDaemon.C:213)
>
> How the PostgreSQL community likes us to deal with this?
ECPGconnect() in src/interfaces/ecpg/ecpglib/connect.c is rather
careful in freeing any resource it allocates with ecpg_strdup() in the
various code paths where the call returns, particularly after calling
PQconnectdbParams(), and a quick installcheck run on a valgrind'ed
instance does not show me any leaks similar to what you have here
after testing on HEAD and REL_11_STABLE. It is likely possible that
we are missing something though, so could you send a test case to
reproduce what you are seeing?
--
Michael
