Re: [BUGS] (Benign ?) Libpq memory leak - Mailing list pgsql-bugs
| From | Michael Cress |
|---|---|
| Subject | Re: [BUGS] (Benign ?) Libpq memory leak |
| Date | |
| Msg-id | SN1PR19MB0654C7F7F5683B55F929B2889B590@SN1PR19MB0654.namprd19.prod.outlook.com Whole thread Raw |
| In response to | Re: [BUGS] (Benign ?) Libpq memory leak (Andres Freund <andres@anarazel.de>) |
| List | pgsql-bugs |
Andres,
I found and installed the package that you suggested, but it didn’t seem to rectify the problem with the valgrind output. I researched why this might be happening and came across an article that mentioned something about the library being unloaded prior to valgrind being able to determine the symbol. With that in mind, I rebuilt every dependency up to and including Postgresql from source sand, after static linking to my application, my Valgrind output is now showing no memory leaks. I will spend some time exploring this issue when I get an opportunity but at this time I am going to consider this issue as resolved. Thank you very much for your suggestion and quick response; it is greatly appreciated.
Regards,
Michael Cress
From: Andres Freund
Sent: Sunday, February 12, 2017 3:54 PM
To: Michael Cress
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] (Benign ?) Libpq memory leak
On 2017-02-12 21:40:11 +0000, Michael Cress wrote:
> I have noticed a memory leak in libpq. Running the following code from the context of a worker thread leaks 1024 bytes:
>
> const char conninfo[] = "dbname=testdb host=localhost user=testaccount password=password";
> PGconn *conn;
> PGresult *res;
> int nFields, i, j;
>
> printf("Opening connection to database\n");
> conn = PQconnectdb(conninfo);
>
> /* PQ statements used to be here but were removed when the leak was noticed. They executed fine and did not contribute to the leak. */
>
> printf("Closing connection to database\n");
> PQfinish(conn);
> ==19194== HEAP SUMMARY:
> ==19194== in use at exit: 5,324 bytes in 25 blocks
> ==19194== total heap usage: 33,714 allocs, 33,689 frees, 5,311,760 bytes allocated
> ==19194==
> ==19194== 40 bytes in 1 blocks are definitely lost in loss record 3 of 9
> ==19194== at 0x402E23C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
> ==19194== by 0x7DE3E42: ???
> ==19194== by 0x7DE4F5E: ???
> ==19194== by 0x7DDF577: ???
> ==19194== by 0x7DD0698: ???
> ==19194== by 0x7DD0EAA: ???
> ==19194== by 0x7DD184E: ???
> ==19194== by 0x42D6C18: ???
> <Redacted application call stack specific to application>
> ==19194==
> ==19194== 984 bytes in 1 blocks are definitely lost in loss record 8 of 9
> ==19194== at 0x402E23C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
> ==19194== by 0x7DE4BC3: ???
> ==19194== by 0x7DDF557: ???
> ==19194== by 0x7DD067E: ???
> ==19194== by 0x7DD0EAA: ???
> ==19194== by 0x7DD184E: ???
> ==19194== by 0x42D6C18: ???
> <Redacted application call stack specific to application>
Without libpq call-stack it's hard to make useful comments here. Could
you recompile with debugging symbols / install debugging symbols?
> The system environment is x86 running an up-to-date Ubuntu 16.10. The version of Postgresql installed is “9.5.5”. I have not performed any tests on other environments. This test was conducted against a development database containing data as well as a test database containing no data.
IIRC recent ubuntu version provide dbgsym packages in a separate
repository that you need to enable.
Greetings,
Andres Freund
pgsql-bugs by date: