I'm writing a server application in C that needs to interact with a postgre
database, but on my development server I'm getting tons of memory errors from
valgrind. There are enough of them that it's causing problems, like data
stored in a char* is magically changing after calling PQexec().
I'm not having any of these issues on my production server, which is odd.
Maybe there is some configuration difference.
My development server was initially running 8.4.4 on Gentoo. I downgraded to
8.1.21 (still on Gentoo) to match my CentOS production server to see if the
problems would go away, but they didn't.
I set up a simple test program that links to libpq to see if it was a problem
in libpq or with my program.
#include <stdio.h>
#include <stdlib.h>
#include "libpq-fe.h"
int main(int argc, char **argv)
{
PGconn *conn;
conn = PQconnectdb("dbname=mydb");
if(PQstatus(conn) != CONNECTION_OK)
{
fprintf(stderr, "connection failed: %s\n", PQerrorMessage(conn));
PQfinish(conn);
return 1;
}
char* q = "SELECT * from mytable;";
PGresult *res = PQexec(conn, q);
if(PQresultStatus(res) != PGRES_TUPLES_OK)
{
fprintf(stderr, "comamnd failed: %s\n", PQerrorMessage(conn));
PQfinish(conn);
return 1;
}
PQclear(res);
PQfinish(conn);
return 0;
}
I compiled it using this command: gcc test.c -lpq
Then I ran it through valgrind 3.5.0 using:
valgrind --tool=memcheck --leak-check=full ./a.out
This is the summary from valgrind on the problem server.
==22234== HEAP SUMMARY:
==22234== in use at exit: 292 bytes in 11 blocks
==22234== total heap usage: 122 allocs, 112 frees, 51,747 bytes allocated
==22234==
==22234== 292 (52 direct, 240 indirect) bytes in 1 blocks are definitely lost
in loss record 11 of 11
==22234== at 0x4C260AE: malloc (vg_replace_malloc.c:195)
==22234== by 0x5130C4C: nss_parse_service_list (in /lib64/libc-2.12.1.so)
==22234== by 0x5131425: __nss_database_lookup (in /lib64/libc-2.12.1.so)
==22234== by 0x641536F: ???
==22234== by 0x6415FB4: ???
==22234== by 0x50EFF4C: getpwuid_r@@GLIBC_2.2.5 (in /lib64/libc-2.12.1.so)
==22234== by 0x50EF83E: getpwuid (in /lib64/libc-2.12.1.so)
==22234== by 0x4E46708: pqGetpwuid (in
/usr/lib64/postgresql-8.1/lib64/libpq.so.4.1)
==22234== by 0x4E354D6: pg_fe_getauthname (in
/usr/lib64/postgresql-8.1/lib64/libpq.so.4.1)
==22234== by 0x4E37CF9: conninfo_parse (in
/usr/lib64/postgresql-8.1/lib64/libpq.so.4.1)
==22234== by 0x4E37DD7: connectOptions1 (in
/usr/lib64/postgresql-8.1/lib64/libpq.so.4.1)
==22234== by 0x4E389C0: PQconnectStart (in
/usr/lib64/postgresql-8.1/lib64/libpq.so.4.1)
==22234==
==22234== LEAK SUMMARY:
==22234== definitely lost: 52 bytes in 1 blocks
==22234== indirectly lost: 240 bytes in 10 blocks
==22234== possibly lost: 0 bytes in 0 blocks
==22234== still reachable: 0 bytes in 0 blocks
==22234== suppressed: 0 bytes in 0 blocks
==22234==
==22234== For counts of detected and suppressed errors, rerun with: -v
==22234== Use --track-origins=yes to see where uninitialised values come from
==22234== ERROR SUMMARY: 255 errors from 76 contexts (suppressed: 6 from 6)
These are the first two errors from valgrind. If more are needed, I can send
them.
==22234== Invalid read of size 8
==22234== at 0x515EE03: __strcmp_ssse3 (in /lib64/libc-2.12.1.so)
==22234== by 0x4E377D4: conninfo_parse (in
/usr/lib64/postgresql-8.1/lib64/libpq.so.4.1)
==22234== by 0x4E37DD7: connectOptions1 (in
/usr/lib64/postgresql-8.1/lib64/libpq.so.4.1)
==22234== by 0x4E389C0: PQconnectStart (in
/usr/lib64/postgresql-8.1/lib64/libpq.so.4.1)
==22234== by 0x4E38A05: PQconnectdb (in
/usr/lib64/postgresql-8.1/lib64/libpq.so.4.1)
==22234== by 0x40097C: main (in /home/casey/a.out)
==22234== Address 0x601baa8 is 8 bytes inside a block of size 12 alloc'd
==22234== at 0x4C260AE: malloc (vg_replace_malloc.c:195)
==22234== by 0x50CBB41: strdup (in /lib64/libc-2.12.1.so)
==22234== by 0x4E3766B: conninfo_parse (in
/usr/lib64/postgresql-8.1/lib64/libpq.so.4.1)
==22234== by 0x4E37DD7: connectOptions1 (in
/usr/lib64/postgresql-8.1/lib64/libpq.so.4.1)
==22234== by 0x4E389C0: PQconnectStart (in
/usr/lib64/postgresql-8.1/lib64/libpq.so.4.1)
==22234== by 0x4E38A05: PQconnectdb (in
/usr/lib64/postgresql-8.1/lib64/libpq.so.4.1)
==22234== by 0x40097C: main (in /home/casey/a.out)
==22234==
==22234== Invalid read of size 8
==22234== at 0x515FA54: __strcmp_ssse3 (in /lib64/libc-2.12.1.so)
==22234== by 0x4E377D4: conninfo_parse (in
/usr/lib64/postgresql-8.1/lib64/libpq.so.4.1)
==22234== by 0x4E37DD7: connectOptions1 (in
/usr/lib64/postgresql-8.1/lib64/libpq.so.4.1)
==22234== by 0x4E389C0: PQconnectStart (in
/usr/lib64/postgresql-8.1/lib64/libpq.so.4.1)
==22234== by 0x4E38A05: PQconnectdb (in
/usr/lib64/postgresql-8.1/lib64/libpq.so.4.1)
==22234== by 0x40097C: main (in /home/casey/a.out)
==22234== Address 0x601baa8 is 8 bytes inside a block of size 12 alloc'd
==22234== at 0x4C260AE: malloc (vg_replace_malloc.c:195)
==22234== by 0x50CBB41: strdup (in /lib64/libc-2.12.1.so)
==22234== by 0x4E3766B: conninfo_parse (in
/usr/lib64/postgresql-8.1/lib64/libpq.so.4.1)
==22234== by 0x4E37DD7: connectOptions1 (in
/usr/lib64/postgresql-8.1/lib64/libpq.so.4.1)
==22234== by 0x4E389C0: PQconnectStart (in
/usr/lib64/postgresql-8.1/lib64/libpq.so.4.1)
==22234== by 0x4E38A05: PQconnectdb (in
/usr/lib64/postgresql-8.1/lib64/libpq.so.4.1)
==22234== by 0x40097C: main (in /home/casey/a.out)
This is what I get from valgrind on my production server (CentOS 5.4 with
postgresql 8.1.21)
==21941== HEAP SUMMARY:
==21941== in use at exit: 0 bytes in 0 blocks
==21941== total heap usage: 240 allocs, 240 frees, 65,725 bytes allocated
==21941==
==21941== All heap blocks were freed -- no leaks are possible
==21941==
==21941== For counts of detected and suppressed errors, rerun with: -v
==21941== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 49 from 10)
My Gentoo machine's setup
AMD64
Linux 2.6.35.4
gcc 4.4.4
glibc 2.12.1
postgresql 8.1.21
Thanks
--
Casey Jones
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
