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
Attachment:
signature.asc
Description: PGP signature
