Re: memory leak occur when disconnect database

Your test case doesn't build, but I've attached a trivially tweaked one
that does.

Valgrind's report (valgrind --leak-check=full ./test) on my Ubuntu 9.04
machine with Pg 8.3.7 is:

==23382== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely
lost in loss record 1 of 4
==23382== at 0x4026FDE: malloc (vg_replace_malloc.c:207)
==23382== by 0x4211548: nss_parse_service_list (nsswitch.c:547)
==23382== by 0x4211E25: __nss_database_lookup (nsswitch.c:134)
==23382== by 0x4B61F5B: ???
==23382== by 0x4B6400C: ???
==23382== by 0x41B7A51: getpwuid_r@@GLIBC_2.1.2 (getXXbyYY_r.c:253)
==23382== by 0x42A87DD: (within /usr/lib/libpq.so.5.1)
==23382== by 0x4292955: (within /usr/lib/libpq.so.5.1)
==23382== by 0x429749E: (within /usr/lib/libpq.so.5.1)
==23382== by 0x4297528: (within /usr/lib/libpq.so.5.1)
==23382== by 0x4297E24: PQsetdbLogin (in /usr/lib/libpq.so.5.1)
==23382== by 0x4053563: ECPGconnect (in /usr/lib/libecpg.so.6.0)
==23382==
==23382== LEAK SUMMARY:
==23382== definitely lost: 36 bytes in 1 blocks.
==23382== indirectly lost: 120 bytes in 10 blocks.
==23382== possibly lost: 0 bytes in 0 blocks.
==23382== still reachable: 220 bytes in 1 blocks.
==23382== suppressed: 0 bytes in 0 blocks.

If you're seeing the same output, then the issue you're running into is
libnss caching NSS services list ( /etc/services, plus LDAP/NIS services
etc) when it's first used. This memory is "leaked" in the sense that
it's not free()d when the program exits, but that doesn't matter _at_
_all_. When the program exits, the OS cleans up its allocations anyway,
so the free() would only be wasting CPU doing work that's about to be
thrown away and slowing down the program's exit in the process. It'd
also open up all sorts of exciting issues if another atexit hook tried
to use NSS...

This "leak" should be added to your valgrind suppressions file and
ignored. You can re-run valgrind with:

valgrind --leak-check=full --gen-suppressions=all ./test

to generate a suppressions file, but you'll usually want to edit it to
make it a bit less specific. For example, this suppressions entry should
do the trick:

{
libnss_service_cache
Memcheck:Leak
fun:malloc
fun:nss_parse_service_list
fun:__nss_database_lookup
}

If I re-run valgrind with the suppressions entry (in the file
"ecpg_suppressions")

valgrind --leak-check=full --suppressions=ecpg_suppressions ./test

I get no reported leaks.

Valgrind is a great tool, but you must learn how to identify false
positives and tell the difference between a leak that matters (say 1kb
allocated and not freed in a loop that runs once per second) and a leak
that doesn't.

--
Craig Ringer