lib/libecpg.so.6.11 && valgrind

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