Thread: Memory leak somewhere at PQconnectdb?
Hi all, I'm running one of my programs with valgrind to check for memory leaks and I'm seeing something like this: ==13207== 4 bytes in 1 blocks are still reachable in loss record 1 of 256 ==13207== at 0x4026864: malloc (vg_replace_malloc.c:236) ==13207== by 0x43343BD: ??? (in /lib/libcrypto.so.0.9.8) ==13207== by 0x4334A6B: CRYPTO_malloc (in /lib/libcrypto.so.0.9.8) ==13207== by 0x438D199: engine_cleanup_add_last (in /lib/libcrypto.so.0.9.8) ==13207== by 0x438DA19: ENGINE_add (in /lib/libcrypto.so.0.9.8) ==13207== by 0x4393712: ENGINE_load_padlock (in /lib/libcrypto.so.0.9.8) ==13207== by 0x438FCCB: ENGINE_load_builtin_engines (in /lib/libcrypto.so.0.9.8) ==13207== by 0x43F32B9: OPENSSL_config (in /lib/libcrypto.so.0.9.8) ==13207== by 0x407E80B: ??? (in /usr/lib/libpq.so.5.2) ==13207== by 0x406FA85: PQconnectPoll (in /usr/lib/libpq.so.5.2) ==13207== by 0x407019A: ??? (in /usr/lib/libpq.so.5.2) ==13207== by 0x4071952: PQconnectdb (in /usr/lib/libpq.so.5.2) and ==13207== 8 bytes in 1 blocks are still reachable in loss record 2 of 256 ==13207== at 0x4026864: malloc (vg_replace_malloc.c:236) ==13207== by 0x43343BD: ??? (in /lib/libcrypto.so.0.9.8) ==13207== by 0x4334A6B: CRYPTO_malloc (in /lib/libcrypto.so.0.9.8) ==13207== by 0x4393D98: BUF_strndup (in /lib/libcrypto.so.0.9.8) ==13207== by 0x4393E33: BUF_strdup (in /lib/libcrypto.so.0.9.8) ==13207== by 0x43F2E47: CONF_module_add (in /lib/libcrypto.so.0.9.8) ==13207== by 0x43918A3: ENGINE_add_conf_module (in /lib/libcrypto.so.0.9.8) ==13207== by 0x43F326B: OPENSSL_load_builtin_modules (in /lib/libcrypto.so.0.9.8) ==13207== by 0x43F32B4: OPENSSL_config (in /lib/libcrypto.so.0.9.8) ==13207== by 0x407E80B: ??? (in /usr/lib/libpq.so.5.2) ==13207== by 0x406FA85: PQconnectPoll (in /usr/lib/libpq.so.5.2) ==13207== by 0x407019A: ??? (in /usr/lib/libpq.so.5.2) I'm using PQconnectdb to open connections and PQfinish to finish them. I was wondering if there're any leaks reported for PQconnectdb, any other hints would be greatly appreciated. Thanks in advance, Antonio
Antonio Vieiro <antonio@antonioshome.net> writes:
> I'm running one of my programs with valgrind to check for memory leaks
> and I'm seeing something like this:
> ==13207== 4 bytes in 1 blocks are still reachable in loss record 1 of 256
These are not bugs; they are just permanent allocations that are still
there when the program exits. Even if they were bugs, complaining to us
is rather pointless since it's openssl that is making the allocations.
regards, tom lane
On 01/09/11 22:08, Antonio Vieiro wrote: > Hi all, > > I'm running one of my programs with valgrind to check for memory leaks > and I'm seeing something like this: You only get the one report, though, right? No matter how many times PQconnectdb is run in a loop? It's internal stuff within OpenSSL. If you really want to you can call: CONF_modules_free() before your program terminates, to make sure OpenSSL cleans up its data structures. Just make sure nobody else has registered an atexit() handler that touches OpenSSL or you'll get fireworks. PostgreSQL (libpq) should not be responsible for cleaning up OpenSSL, and *cannot* be reliably responsible for it. If libpq tried to clean up OpenSSL it might well "clean" it while other libraries or the main application code was still using it for something else. If you want to avoid this warning, call OPENSSL_config yourself before doing anything in libpq, and call CONF_modules_free before exit. That way libpq's call to OPENSSL_config becomes a no-op and you have full control of OpenSSL's init and cleanup. Even better, add a valgrind suppressions file for the warnings and ignore them. They are "leaks" only in the sense that a static variable is a leak, ie not at all. If you see that the program grows if you run it many times in a loop, and you get more and more leak records for every loop, *THEN* there might be a problem. -- Craig Ringer
Craig Ringer <ringerc@ringerc.id.au> writes:
> Even better, add a valgrind suppressions file for the warnings and
> ignore them. They are "leaks" only in the sense that a static variable
> is a leak, ie not at all.
Yeah, the bottom line here is that valgrind will warn about many things
that are not genuine problems. You need to learn how to judge the tool's
reports. A single allocation that is still reachable at program exit is
almost never a real problem. If it's unreachable, or there's a lot of
instances, it may be worth worrying about.
regards, tom lane
Hi all, I now know it's somewhat an "academic exercise" of little practical importance, thanks for the clarification!! Cheers, Antonio 2011/9/2 Tom Lane <tgl@sss.pgh.pa.us>: > Craig Ringer <ringerc@ringerc.id.au> writes: >> Even better, add a valgrind suppressions file for the warnings and >> ignore them. They are "leaks" only in the sense that a static variable >> is a leak, ie not at all. > > Yeah, the bottom line here is that valgrind will warn about many things > that are not genuine problems. You need to learn how to judge the tool's > reports. A single allocation that is still reachable at program exit is > almost never a real problem. If it's unreachable, or there's a lot of > instances, it may be worth worrying about. > > regards, tom lane >