I'm developing a program in C that acquires data from an I/O card and
stores values in postgresql.
I noticed that the program uses more and more ram, so I decided to debug
it with valgrind, and I found
==28449== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely
lost in loss record 2 of 8
==28449== at 0x402137E: malloc (in
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==28449== by 0x4154799: (within /lib/libc-2.5.so)
==28449== by 0x4154E85: __nss_database_lookup (in /lib/libc-2.5.so)
==28449== by 0x4459079: ???
==28449== by 0x4459DAA: ???
==28449== by 0x4112294: getpwuid_r (in /lib/libc-2.5.so)
==28449== by 0x4111C98: getpwuid (in /lib/libc-2.5.so)
==28449== by 0x4082A63: (within /usr/lib/postgresql-8.2/lib/libpq.so.5.0)
==28449== 40 bytes in 5 blocks are indirectly lost in loss record 3 of 8
==28449== at 0x402137E: malloc (in
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==28449== by 0x41543BB: __nss_lookup_function (in /lib/libc-2.5.so)
==28449== by 0x4459099: ???
==28449== by 0x4459DAA: ???
==28449== by 0x4112294: getpwuid_r (in /lib/libc-2.5.so)
==28449== by 0x4111C98: getpwuid (in /lib/libc-2.5.so)
==28449== by 0x4082A63: (within /usr/lib/postgresql-8.2/lib/libpq.so.5.0)
==28449== 80 bytes in 5 blocks are indirectly lost in loss record 6 of 8
==28449== at 0x402137E: malloc (in
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==28449== by 0x4144176: tsearch (in /lib/libc-2.5.so)
==28449== by 0x415437D: __nss_lookup_function (in /lib/libc-2.5.so)
==28449== by 0x4459099: ???
==28449== by 0x4459DAA: ???
==28449== by 0x4112294: getpwuid_r (in /lib/libc-2.5.so)
==28449== by 0x4111C98: getpwuid (in /lib/libc-2.5.so)
==28449== by 0x4082A63: (within /usr/lib/postgresql-8.2/lib/libpq.so.5.0)
Do you have any hint to better identify the problem? Server and client
are running gentoo 2007.0 x86 stable using CFLAGS="-march=i686 -mmmx
-msse -msse2 -msse3 -Os -pipe -fomit-frame-pointer"
--
Non c'e' piu' forza nella normalita', c'e' solo monotonia.