Memory leak somewhere at PQconnectdb?

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>: