Thread: Memory leak
I have found a memory leak in the libpq library for postrgesql 7.4.3. The code sample in the attached file will produce the error.
I used Valgrind(http://valgrind.kde.org/) which is an open source memory profiler application in order to find the problem.
Machine: Pentium 4
OS: Linux Fedora Core1
According to Valgrind if an application attempts to make 2 or more connections to the database then memory will be lost for every connection except the first.
Here is the error that I see from Valgrind for 2 separate connections:
==8980== 56 bytes in 2 blocks are definitely lost in loss record 1 of 1
==8980== at 0x38E68E: malloc (vg_replace_malloc.c:153)
==8980== by 0x13DE9B: __libc_res_nsend (in /lib/libresolv-2.3.2.so)
==8980== by 0x13CC12: __libc_res_nquery (in /lib/libresolv-2.3.2.so)
==8980== by 0x13D309: __libc_res_nquerydomain (in /lib/libresolv-2.3.2.so)
==8980== by 0x13CF0F: __libc_res_nsearch (in /lib/libresolv-2.3.2.so)
==8980== by 0x37705D: ???
==8980== by 0x62AD25: gaih_inet (in /lib/libc-2.3.2.so)
==8980== by 0x62B923: __GI_getaddrinfo (in /lib/libc-2.3.2.so)
==8980== by 0xDF3661: getaddrinfo_all (in /usr/lib/libpq.so.3.1)
==8980== by 0xDE4EBB: (within /usr/lib/libpq.so.3.1)
==8980== by 0xDE4469: PQconnectStart (in /usr/lib/libpq.so.3.1)
==8980== by 0xDE43F1: PQconnectdb (in /usr/lib/libpq.so.3.1)
==8980== by 0x8048684: main (in /home/squin/yo)
==8980== by 0x579BBE: __libc_start_main (in /lib/libc-2.3.2.so)
==8980== by 0x804854C: (within /home/squin/yo)
Any help on this issue is greatly appreciated.
Thanks
Spencer Quin
Web Software Developer
Reseach In Motion
' (519) 888-7465 x2596
Attachment
"Spencer Quin" <squin@rim.com> writes:
> I have found a memory leak in the libpq library for postrgesql 7.4.3.
> The code sample in the attached file will produce the error.
The traceback says that the leak is in libresolv, not libpq. I'm not
sure it's really a leak at all --- I'd expect libresolv to do some
internal caching, and this looks like it could be data that's just being
held onto for possible reuse. But in any case you want to file this
report with somebody else.
regards, tom lane
That's a good theory. I will definitely check it out.
I appreciate you looking into this Tom.
Spence
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]=20
Sent: Tuesday, August 24, 2004 4:13 PM
To: Spencer Quin
Cc: pgsql-bugs@postgresql.org; Thomas Parry; Geoffrey Stitt
Subject: Re: [BUGS] Memory leak=20
"Spencer Quin" <squin@rim.com> writes:
> I have found a memory leak in the libpq library for postrgesql 7.4.3.
> The code sample in the attached file will produce the error.
The traceback says that the leak is in libresolv, not libpq. I'm not
sure it's really a leak at all --- I'd expect libresolv to do some
internal caching, and this looks like it could be data that's just being
held onto for possible reuse. But in any case you want to file this
report with somebody else.
regards, tom lane
"Spencer Quin" <squin@rim.com> writes:
> Tom, I am not sure if my original message made it onto a forum or
> knowledge base but I was wondering if it would be possible for you to
> take it down if it is? There may potentially be some sensitive
> information in it.
The bugs list is archived, yes, not to mention propagated onto
newsgroups. You should probably have thought before posting.
You could perhaps get Marc to remove it from the archives but that's
not going to cause all the copies to go away.
regards, tom lane
Tom, I am not sure if my original message made it onto a forum or
knowledge base but I was wondering if it would be possible for you to
take it down if it is? There may potentially be some sensitive
information in it.
Thanks
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]=20
Sent: Tuesday, August 24, 2004 4:13 PM
To: Spencer Quin
Cc: pgsql-bugs@postgresql.org; Thomas Parry; Geoffrey Stitt
Subject: Re: [BUGS] Memory leak=20
"Spencer Quin" <squin@rim.com> writes:
> I have found a memory leak in the libpq library for postrgesql 7.4.3.
> The code sample in the attached file will produce the error.
The traceback says that the leak is in libresolv, not libpq. I'm not
sure it's really a leak at all --- I'd expect libresolv to do some
internal caching, and this looks like it could be data that's just being
held onto for possible reuse. But in any case you want to file this
report with somebody else.
regards, tom lane