(Benign ?) Libpq memory leak

Hello:

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);

Results for “Valgrind –leak-check=full “

==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>
==19194==
==19194== LEAK SUMMARY:
==19194== definitely lost: 1,024 bytes in 2 blocks
==19194== indirectly lost: 0 bytes in 0 blocks
==19194== possibly lost: 0 bytes in 0 blocks
==19194== still reachable: 4,300 bytes in 23 blocks
==19194== suppressed: 0 bytes in 0 blocks
==19194== Reachable blocks (those to which a pointer was found) are not shown.
==19194== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==19194==
==19194== For counts of detected and suppressed errors, rerun with: -v
==19194== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

However, running the exact same code sequence from a simple test main() application does not show the same leak.

Results for “Valgrind –leak-check=full “ for test app

Opening connection to database
Closing connection to database
==19318==
==19318== HEAP SUMMARY:
==19318== in use at exit: 45,120 bytes in 2,861 blocks
==19318== total heap usage: 5,782 allocs, 2,921 frees, 359,938 bytes allocated
==19318==
==19318== LEAK SUMMARY:
==19318== definitely lost: 0 bytes in 0 blocks
==19318== indirectly lost: 0 bytes in 0 blocks
==19318== possibly lost: 0 bytes in 0 blocks
==19318== still reachable: 45,120 bytes in 2,861 blocks
==19318== suppressed: 0 bytes in 0 blocks
==19318== Reachable blocks (those to which a pointer was found) are not shown.
==19318== To see them, rerun with: --leak-check=full --show-leak-kinds=all

Commenting out the code sequence from the threaded application yields the following Valgrind results:

Results for “Valgrind –leak-check=full “ for original threaded application with code sequence commented out and repeating the same testing steps

==19429==
==19429== HEAP SUMMARY:
==19429== in use at exit: 20 bytes in 1 blocks
==19429== total heap usage: 10,850 allocs, 10,849 frees, 577,899 bytes allocated
==19429==
==19429== LEAK SUMMARY:
==19429== definitely lost: 0 bytes in 0 blocks
==19429== indirectly lost: 0 bytes in 0 blocks
==19429== possibly lost: 0 bytes in 0 blocks
==19429== still reachable: 20 bytes in 1 blocks
==19429== suppressed: 0 bytes in 0 blocks
==19429== Reachable blocks (those to which a pointer was found) are not shown.
==19429== To see them, rerun with: --leak-check=full --show-leak-kinds=all

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.

This issue appears benign as I have not yet seen the 1024 byte count increase despite multiple threads executing the same code statements. However, this was a trivial test and not subjected to any sort of load conditions (which would result in concurrent thread execution of the same code) so I cannot guarantee that statement is completely true at this time.

Has this issue been seen before? Is this something I should be concerned about for production use?

Thank you,

Michael Cress