Grzegorz Jaśkiewicz wrote: > Hey folks, > > I am getting leaks on my machine, valgrind points to getpwuid_r called > by libpq's PQConnectDb() > > ==11784== 32,772 bytes in 1 blocks are indirectly lost in loss record 31 of 31 > ==11784== at 0x4004BA2: calloc (vg_replace_malloc.c:397) > ==11784== by 0x63D9FCB: ??? > ==11784== by 0x63C10FD: ??? > ==11784== by 0x63AF5BE: ??? > ==11784== by 0x63AFB4D: ??? > ==11784== by 0x63A0C0E: ??? > ==11784== by 0x63A3520: ??? > ==11784== by 0x63A42BD: ??? > ==11784== by 0x63A4A86: ??? > ==11784== by 0x63A513F: ??? > ==11784== by 0x4949C1: getpwuid_r@@GLIBC_2.1.2 (in /lib/libc-2.8.so) > ==11784== by 0x297F2D: (within /usr/lib/libpq.so.5.1) > ==11784== by 0x283050: (within /usr/lib/libpq.so.5.1) > ==11784== by 0x287118: (within /usr/lib/libpq.so.5.1) > ==11784== by 0x287269: (within /usr/lib/libpq.so.5.1) > ==11784== by 0x2875AE: PQconnectStart (in /usr/lib/libpq.so.5.1) > ==11784== by 0x287601: PQconnectdb (in /usr/lib/libpq.so.5.1) > > > The application fires up few threads once in a while, and they connect > to db on different hosts. > What matters, is that after few days it started to fail in > pthread_create(), because of memory problems. That is kind of odd, considering that getpwuid_r() shouldn't be allocating any memory at all --- in fact, the reason we use it is because we pass the memory it uses for storage. The only thing I can suggest is posting the application source code somewhere in hopes we can see the problem somewhere. I have never heard of a similar report, so odds are there is something wierd happening in your application. -- Bruce Momjian <bruce@xxxxxxxxxx> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
