OK, before Helen drops the flying-elbow on me, I all ready know this is likely the wrong place for this, so feel free to respond to federonline at yahoo dot com

I'm trying to find out if there is a fix for a memory leak in IBPP.

I am using IBPP to interface with the DB via C++ and I got the following reports from Valgrind:

==8361== 292 (52 direct, 240 indirect) bytes in 1 blocks are definitely lost in loss record 1 of 3
==8361== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==8361== by 0x5BB610A: (within /lib/libc-2.9.so)
==8361== by 0x5BB6A06: __nss_database_lookup (in /lib/libc-2.9.so)
==8361== by 0x667233F: ???
==8361== by 0x6674264: ???
==8361== by 0x5B64051: getpwuid_r (in /lib/libc-2.9.so)
==8361== by 0x5B6391E: getpwuid (in /lib/libc-2.9.so)
==8361== by 0x537BE35: ISC_get_user(Firebird::StringBase<Firebird::StringComparator>*, int*, int*, char const*) (isc.cpp:437)
==8361== by 0x539FF39: INET_analyze(Firebird::StringBase<Firebird::PathNameComparator>&, long*, char const*, char const*, bool, unsigned char const*, unsigned short) (inet.cpp:465)
==8361== by 0x53A1C57: analyze(Firebird::StringBase<Firebird::PathNameComparator>&, long*, char const*, bool, unsigned char const*, unsigned short, Firebird::StringBase<Firebird::PathNameComparator>&) (interface.cpp:4866)
==8361== by 0x53AAF6D: REM_attach_database (interface.cpp:350)
==8361== by 0x5389728: isc_attach_database (why.cpp:1163)
==8361==
==8361== LEAK SUMMARY:
==8361== definitely lost: 52 bytes in 1 blocks.
==8361== indirectly lost: 240 bytes in 10 blocks.
==8361== possibly lost: 0 bytes in 0 blocks.
==8361== still reachable: 0 bytes in 0 blocks.
==8361== suppressed: 0 bytes in 0 blocks.



Thanks in advance, and please don't slap me too hard, Helen.
I really need to fix this and I get great help here...

Kurt.
----------------------------------------
Never underestimate the Power of Denial.