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.
signature.asc
Description: OpenPGP digital signature
