Re: leak in libpq, getpwuid

Started by Michael Nacosover 16 years ago7 messagesgeneral
Jump to latest
#1Michael Nacos
m.nacos@gmail.com

just to say I have run into related problems on debian lenny amd64 (postgres
8.3.5, libc-2.7) and centos 5.2 (postgres 8.4.1, libc-2.5)

code as simple as this:

#include <libpq-fe.h>

int main()
{
PGconn *connection = PQconnectdb("user=postgres");
PQfinish(connection);
return 0;
}

gives (run through valgrind --leak-check=full):

==13832==
==13832== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 19 from 2)
==13832== malloc/free: in use at exit: 292 bytes in 11 blocks.
==13832== malloc/free: 131 allocs, 120 frees, 51,532 bytes allocated.
==13832== For counts of detected errors, rerun with: -v
==13832== searching for pointers to 11 not-freed blocks.
==13832== checked 703,248 bytes.
==13832==
==13832== 292 (52 direct, 240 indirect) bytes in 1 blocks are definitely
lost in loss record 1 of 3
==13832== at 0x4C2260E: malloc (vg_replace_malloc.c:207)
==13832== by 0x512852F: (within /lib/libc-2.7.so)
==13832== by 0x5128D06: __nss_database_lookup (in /lib/libc-2.7.so)
==13832== by 0x82A931F: ???
==13832== by 0x82AA02C: ???
==13832== by 0x50E7101: getpwuid_r (in /lib/libc-2.7.so)
==13832== by 0x4E41D38: (within /usr/lib/libpq.so.5.1)
==13832== by 0x4E2E50C: (within /usr/lib/libpq.so.5.1)
==13832== by 0x4E3258F: (within /usr/lib/libpq.so.5.1)
==13832== by 0x4E3260B: (within /usr/lib/libpq.so.5.1)
==13832== by 0x4E32F98: PQconnectStart (in /usr/lib/libpq.so.5.1)
==13832== by 0x4E32FE5: PQconnectdb (in /usr/lib/libpq.so.5.1)
==13832==
==13832== LEAK SUMMARY:
==13832== definitely lost: 52 bytes in 1 blocks.
==13832== indirectly lost: 240 bytes in 10 blocks.
==13832== possibly lost: 0 bytes in 0 blocks.
==13832== still reachable: 0 bytes in 0 blocks.
==13832== suppressed: 0 bytes in 0 blocks.

and

==9466== Invalid free() / delete / delete[]
==9466== at 0x4020FDA: free (vg_replace_malloc.c:233)
==9466== by 0x4158A2D: free_mem (in /lib/libc-2.5.so)
==9466== by 0x41585A6: __libc_freeres (in /lib/libc-2.5.so)
==9466== by 0x401D1E6: _vgnU_freeres (vg_preloaded.c:60)
==9466== by 0x40D9C63: _Exit (in /lib/libc-2.5.so)
==9466== by 0x405EDF3: (below main) (in /lib/libc-2.5.so)
==9466== Address 0x401C8F8 is not stack'd, malloc'd or (recently) free'd
==9466==
==9466== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 45 from 1)
==9466== malloc/free: in use at exit: 0 bytes in 0 blocks.
==9466== malloc/free: 136 allocs, 137 frees, 49,272 bytes allocated.

cheers, Michael

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Michael Nacos (#1)

Michael Nacos <m.nacos@gmail.com> writes:

just to say I have run into related problems on debian lenny amd64 (postgres
8.3.5, libc-2.7) and centos 5.2 (postgres 8.4.1, libc-2.5)

This is not a Postgres bug. You can try filing it against glibc, but
I wouldn't be too surprised if they tell you it's not worth fixing.

regards, tom lane

#3Grzegorz Jaśkiewicz
gryzman@gmail.com
In reply to: Tom Lane (#2)

On Thu, Oct 22, 2009 at 3:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Michael Nacos <m.nacos@gmail.com> writes:

just to say I have run into related problems on debian lenny amd64

(postgres

8.3.5, libc-2.7) and centos 5.2 (postgres 8.4.1, libc-2.5)

This is not a Postgres bug. You can try filing it against glibc, but
I wouldn't be too surprised if they tell you it's not worth fixing.

I tried to fight the same battle, and apparently this is by design.

--
GJ

#4Michael Nacos
m.nacos@gmail.com
In reply to: Grzegorz Jaśkiewicz (#3)

I have just run some tests, the number of lost bytes is always 292, no
matter how many connections are opened and closed.
I guess it's ok, then.

M.

#5Tom Lane
tgl@sss.pgh.pa.us
In reply to: Michael Nacos (#4)

Michael Nacos <m.nacos@gmail.com> writes:

I have just run some tests, the number of lost bytes is always 292, no
matter how many connections are opened and closed.
I guess it's ok, then.

Yeah. I suspect the memory is in fact not "leaked", but valgrind is
somehow missing the link that points to it. You'd have to dig into
the glibc sources to find out for sure though.

regards, tom lane

#6Craig Ringer
craig@2ndquadrant.com
In reply to: Michael Nacos (#4)

Michael Nacos wrote:

I have just run some tests, the number of lost bytes is always 292, no
matter how many connections are opened and closed.
I guess it's ok, then.

Search the archives for a detailed explanation of this issue. The
earlier discussion was about a supposed leak in ecpg.

See:
Message-ID: <022e01ca06e8$898255c0$aa1c10ac@RKC.local>
Message-Id: <1247858675.9349.240.camel@ayaki>
on the -general list.

In brief: while technically a leak, it doesn't matter. Freeing that
memory would only ever be done immediately before a program exits.
Trying to free it introduces finalization ordering issues (what if
someone calls getpwnam(), getpwuid() etc after the cache is freed?) and
wastes CPU cycles. There's no point freeing memory when the whole
program is about to exit and its memory will be more efficiently
released by the OS.

The right answer to this is an addition to the default valgrind
suppressions file, not any change to glibc.

--
Craig Ringer

#7Michael Nacos
m.nacos@gmail.com
In reply to: Craig Ringer (#6)

thanks... I guess if it really mattered it would have come up by now
(since so many interfaces are based on libpq)

toying with the idea of yet another one :-)