Обсуждение: BUG #2684: Memory leak in libpq
The following bug has been logged online:
Bug reference: 2684
Logged by: Milen A. Radev
Email address: milen@radev.net
PostgreSQL version: 8.1.4
Operating system: Debian 3.1
Description: Memory leak in libpq
Details:
Source:
#include <stdio.h>
#include <libpq-fe.h>
int main(int argc, char *argv[])
{
PGconn *pgcon;
int i;
int count = 1;
if(argc > 1)
{
count = atoi(argv[1]);
if(count < 1)
{
count = 1;
}
}
for(i = 0; i < count; i++)
{
pgcon = PQsetdbLogin("mydbserver", "5432", "", "", "mydb", "myuser",
"mypass");
printf("[%d] Successfuly opened connection to the database: pgcon=%p\n",
i, pgcon);
if(PQstatus(pgcon) != CONNECTION_OK)
{
printf("Failed to open connection to the database. Reason: %s\n",
PQerrorMessage(pgcon));
PQfinish(pgcon);
return -1;
}
printf("[%d] Closing the connection: pgcon=%p\n", i, pgcon);
PQfinish(pgcon);
}
return 0;
}
Compile and link:
#gcc -I/usr/local/pgsql/include -o pgtest pgtest.c -L/usr/local/pgsql/lib
-lpq
Valgring output:
#valgrind --tool=memcheck --leak-check=yes --show-reachable=yes
--num-callers=20 --error-limit=no ./pgtest 1
==23845== Memcheck, a memory error detector.
==23845== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==23845== Using LibVEX rev 1658, a library for dynamic binary translation.
==23845== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==23845== Using valgrind-3.2.1, a dynamic binary instrumentation framework.
==23845== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==23845== For more details, rerun with: -v
==23845==
--23845-- DWARF2 CFI reader: unhandled CFI instruction 0:50
--23845-- DWARF2 CFI reader: unhandled CFI instruction 0:50
[0] Successfuly opened connection to the database: pgcon=0x41c8028
[0] Closing the connection: pgcon=0x41c8028
==23845== Invalid free() / delete / delete[]
==23845== at 0x401C285: free (vg_replace_malloc.c:233)
==23845== by 0x414CA3B: (within /lib/tls/libc-2.3.2.so)
==23845== by 0x414C6C4: __libc_freeres (in /lib/tls/libc-2.3.2.so)
==23845== by 0x40184BA: _vgnU_freeres (vg_preloaded.c:60)
==23845== by 0x406A1C5: exit (in /lib/tls/libc-2.3.2.so)
==23845== by 0x405497D: (below main) (in /lib/tls/libc-2.3.2.so)
==23845== Address 0x4026518 is not stack'd, malloc'd or (recently) free'd
==23845==
==23845== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 27 from 2)
==23845== malloc/free: in use at exit: 156 bytes in 11 blocks.
==23845== malloc/free: 124 allocs, 114 frees, 44,465 bytes allocated.
==23845== For counts of detected errors, rerun with: -v
==23845== searching for pointers to 11 not-freed blocks.
==23845== checked 271,364 bytes.
==23845==
==23845==
==23845== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely
lost in loss record 1 of 3
==23845== at 0x401B6EE: malloc (vg_replace_malloc.c:149)
==23845== by 0x4126EE6: (within /lib/tls/libc-2.3.2.so)
==23845== by 0x4126788: __nss_database_lookup (in
/lib/tls/libc-2.3.2.so)
==23845== by 0x42CAAFB: ???
==23845== by 0x40E7D4B: getpwuid_r (in /lib/tls/libc-2.3.2.so)
==23845== by 0x40E7590: getpwuid (in /lib/tls/libc-2.3.2.so)
==23845== by 0x403BD0B: pqGetpwuid (in
/usr/local/pgsql-8.1.4/lib/libpq.so.4.1)
==23845== by 0x402BF77: pg_fe_getauthname (in
/usr/local/pgsql-8.1.4/lib/libpq.so.4.1)
==23845== by 0x402DEE6: conninfo_parse (in
/usr/local/pgsql-8.1.4/lib/libpq.so.4.1)
==23845== by 0x402E123: connectOptions1 (in
/usr/local/pgsql-8.1.4/lib/libpq.so.4.1)
==23845== by 0x402EEE3: PQsetdbLogin (in
/usr/local/pgsql-8.1.4/lib/libpq.so.4.1)
==23845== by 0x804864D: main (in /home/slav/rate_engine/pgtest)
==23845==
==23845==
==23845== 40 bytes in 5 blocks are indirectly lost in loss record 2 of 3
==23845== at 0x401B6EE: malloc (vg_replace_malloc.c:149)
==23845== by 0x4126AAD: __nss_lookup_function (in
/lib/tls/libc-2.3.2.so)
==23845== by 0x42CAB21: ???
==23845== by 0x40E7D4B: getpwuid_r (in /lib/tls/libc-2.3.2.so)
==23845== by 0x40E7590: getpwuid (in /lib/tls/libc-2.3.2.so)
==23845== by 0x403BD0B: pqGetpwuid (in
/usr/local/pgsql-8.1.4/lib/libpq.so.4.1)
==23845== by 0x402BF77: pg_fe_getauthname (in
/usr/local/pgsql-8.1.4/lib/libpq.so.4.1)
==23845== by 0x402DEE6: conninfo_parse (in
/usr/local/pgsql-8.1.4/lib/libpq.so.4.1)
==23845== by 0x402E123: connectOptions1 (in
/usr/local/pgsql-8.1.4/lib/libpq.so.4.1)
==23845== by 0x402EEE3: PQsetdbLogin (in
/usr/local/pgsql-8.1.4/lib/libpq.so.4.1)
==23845== by 0x804864D: main (in /home/slav/rate_engine/pgtest)
==23845==
==23845==
==23845== 80 bytes in 5 blocks are indirectly lost in loss record 3 of 3
==23845== at 0x401B6EE: malloc (vg_replace_malloc.c:149)
==23845== by 0x4115143: tsearch (in /lib/tls/libc-2.3.2.so)
==23845== by 0x4126A6E: __nss_lookup_function (in
/lib/tls/libc-2.3.2.so)
==23845== by 0x42CAB21: ???
==23845== by 0x40E7D4B: getpwuid_r (in /lib/tls/libc-2.3.2.so)
==23845== by 0x40E7590: getpwuid (in /lib/tls/libc-2.3.2.so)
==23845== by 0x403BD0B: pqGetpwuid (in
/usr/local/pgsql-8.1.4/lib/libpq.so.4.1)
==23845== by 0x402BF77: pg_fe_getauthname (in
/usr/local/pgsql-8.1.4/lib/libpq.so.4.1)
==23845== by 0x402DEE6: conninfo_parse (in
/usr/local/pgsql-8.1.4/lib/libpq.so.4.1)
==23845== by 0x402E123: connectOptions1 (in
/usr/local/pgsql-8.1.4/lib/libpq.so.4.1)
==23845== by 0x402EEE3: PQsetdbLogin (in
/usr/local/pgsql-8.1.4/lib/libpq.so.4.1)
==23845== by 0x804864D: main (in /home/slav/rate_engine/pgtest)
==23845==
==23845== LEAK SUMMARY:
==23845== definitely lost: 36 bytes in 1 blocks.
==23845== indirectly lost: 120 bytes in 10 blocks.
==23845== possibly lost: 0 bytes in 0 blocks.
==23845== still reachable: 0 bytes in 0 blocks.
==23845== suppressed: 0 bytes in 0 blocks.
The same test programme has grown (after ~1 million iterations) from 2KB to
around 40MB used physical memory (as reported by "top").
We've tested the libraries from the "libpq-dev" (8.1.4-6~bpo.1) package from
backports.org and the libraries built from source (8.1.4).
"Milen A. Radev" <milen@radev.net> writes:
> The same test programme has grown (after ~1 million iterations) from 2KB to
> around 40MB used physical memory (as reported by "top").
I couldn't duplicate any such leak using your test program here.
What authentication method is being selected by your pg_hba.conf
file, and what are your pg_config settings?
regards, tom lane
On 10/10/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Milen A. Radev" <milen@radev.net> writes: > > The same test programme has grown (after ~1 million iterations) from 2KB to > > around 40MB used physical memory (as reported by "top"). > > I couldn't duplicate any such leak using your test program here. > What authentication method is being selected by your pg_hba.conf > file, and what are your pg_config settings? The client and the server were on different machines - that's why I believe "md5" was used. I'm sending only the client machine's pg_config output. Tell me if you need the server's too. Client's pg_config (built from source) output: DOCDIR = /usr/local/pgsql-8.1.4/doc INCLUDEDIR = /usr/local/pgsql-8.1.4/include PKGINCLUDEDIR = /usr/local/pgsql-8.1.4/include INCLUDEDIR-SERVER = /usr/local/pgsql-8.1.4/include/server LIBDIR = /usr/local/pgsql-8.1.4/lib PKGLIBDIR = /usr/local/pgsql-8.1.4/lib LOCALEDIR = MANDIR = /usr/local/pgsql-8.1.4/man SHAREDIR = /usr/local/pgsql-8.1.4/share SYSCONFDIR = /usr/local/pgsql-8.1.4/etc PGXS = /usr/local/pgsql-8.1.4/lib/pgxs/src/makefiles/pgxs.mk CONFIGURE = '--prefix=/usr/local/pgsql-8.1.4' CC = gcc CPPFLAGS = -D_GNU_SOURCE CFLAGS = -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing CFLAGS_SL = -fpic LDFLAGS = -Wl,-rpath,/usr/local/pgsql-8.1.4/lib LDFLAGS_SL = LIBS = -lpgport -lz -lreadline -lcrypt -lresolv -lnsl -ldl -lm VERSION = PostgreSQL 8.1.4 Client's pg_config (from the backports.org package) output: BINDIR = /usr/lib/postgresql/8.1/bin DOCDIR = /usr/share/doc/postgresql-doc-8.1 INCLUDEDIR = /usr/include/postgresql PKGINCLUDEDIR = /usr/include/postgresql INCLUDEDIR-SERVER = /usr/include/postgresql/8.1/server LIBDIR = /usr/lib PKGLIBDIR = /usr/lib/postgresql/8.1/lib LOCALEDIR = /usr/share/locale MANDIR = /usr/share/postgresql/8.1/man SHAREDIR = /usr/share/postgresql/8.1 SYSCONFDIR = /etc/postgresql PGXS = /usr/lib/postgresql/8.1/lib/pgxs/src/makefiles/pgxs.mk CONFIGURE = '--build=i386-linux' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=/usr/lib/postgresql-8.1' '--srcdir=.' '--disable-maintainer-mode' '--mandir=/usr/share/postgresql/8.1/man' '--with-docdir=/usr/share/doc/postgresql-doc-8.1' '--datadir=/usr/share/postgresql/8.1' '--bindir=/usr/lib/postgresql/8.1/bin' '--includedir=/usr/include/postgresql/' '--enable-nls' '--enable-integer-datetimes' '--enable-thread-safety' '--enable-debug' '--disable-rpath' '--with-tcl' '--with-perl' '--with-python' '--with-pam' '--with-krb5' '--with-openssl' '--with-gnu-ld' '--with-tclconfig=/usr/lib/tcl8.4' '--with-tkconfig=/usr/lib/tk8.4' '--with-includes=/usr/include/tcl8.4' '--with-pgport=5432' 'CFLAGS=-g -Wall -O2 -fPIC' 'LDFLAGS=-Wl,--as-needed' 'CC=cc' 'build_alias=i386-linux' CC = cc CPPFLAGS = -D_GNU_SOURCE -I/usr/include/tcl8.4 CFLAGS = -g -Wall -O2 -fPIC -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wendif-labels -fno-strict-aliasing -g CFLAGS_SL = -fpic LDFLAGS = -Wl,--as-needed LDFLAGS_SL = LIBS = -lpgport -lpam -lssl -lcrypto -lkrb5 -lz -lreadline -lcrypt -lresolv -lnsl -ldl -lm VERSION = PostgreSQL 8.1.4 Server's pg_hba.conf: # Database administrative login by UNIX sockets local all postgres ident sameuser # TYPE DATABASE USER CIDR-ADDRESS METHOD # "local" is for Unix domain socket connections only local all all ident sameuser # IPv4 local connections: host all all 127.0.0.1/32 md5 host all all 10.0.0.0/8 md5 # IPv6 local connections: host all all ::1/128 md5 -- Milen A. Radev
"Milen A. Radev" <milen@radev.net> writes:
> On 10/10/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I couldn't duplicate any such leak using your test program here.
> The client and the server were on different machines - that's why I
> believe "md5" was used. I'm sending only the client machine's
> pg_config output. Tell me if you need the server's too.
I cannot duplicate a leak using a cross-machine connection with md5
auth, either. I tested this using Fedora Core 5 and the current FC5
libpq (postgresql-libs-8.1.4-1.FC5.1 RPM).
I'm wondering if the leak you see is actually the fault of the glibc
version on your machine.
regards, tom lane
On 10/10/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Milen A. Radev" <milen@radev.net> writes: > > On 10/10/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> I couldn't duplicate any such leak using your test program here. > > > The client and the server were on different machines - that's why I > > believe "md5" was used. I'm sending only the client machine's > > pg_config output. Tell me if you need the server's too. > > I cannot duplicate a leak using a cross-machine connection with md5 > auth, either. I tested this using Fedora Core 5 and the current FC5 > libpq (postgresql-libs-8.1.4-1.FC5.1 RPM). > > I'm wondering if the leak you see is actually the fault of the glibc > version on your machine. You're most probably right - I could reproduce this results only with libc6 2.3.x (Slackware 9.1, Debian stable), but not with version 2.4 (FC5). -- Milen A. Radev