Обсуждение: BUG #2684: Memory leak in libpq

Поиск
Список
Период
Сортировка

BUG #2684: Memory leak in libpq

От
"Milen A. Radev"
Дата:
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).

Re: BUG #2684: Memory leak in libpq

От
Tom Lane
Дата:
"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

Re: BUG #2684: Memory leak in libpq

От
"Milen A. Radev"
Дата:
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

Re: BUG #2684: Memory leak in libpq

От
Tom Lane
Дата:
"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

Re: BUG #2684: Memory leak in libpq

От
"Milen A. Radev"
Дата:
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

Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера