Re: nslcd eats up all memory

[Arthur de Jong <arthur [at] arthurdejong.org>]

On Sun, 2010-11-21 at 00:47 +0100, Peter Slickers wrote:
> A bug causing similar symptomes has been uncovered and fixed recently
> in PADL libnss-ldap. See Ubuntu's bugtracker for details:
> 
> https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/292971

I think this is a different memory leak. So far I've tracked it down
(using your feedback, thanks for that) to some memory that is not
properly de-allocated when following referrals.

The relevant stack trace from valgrind is:

16,736 (80 direct, 16,656 indirect) bytes in 1 blocks are definitely lost in 
loss record 47 of 55
   at 0x402328F: calloc (vg_replace_malloc.c:467)
   by 0x4218CDF: ber_memcalloc_x (in /usr/lib/liblber-2.4.so.2.5.6)
   by 0x408F0A0: ldap_send_server_request (in /usr/lib/libldap_r-2.4.so.2.5.6)
   by 0x408FEB1: ldap_chase_v3referrals (in /usr/lib/libldap_r-2.4.so.2.5.6)
   by 0x407B0A3: ldap_result (in /usr/lib/libldap_r-2.4.so.2.5.6)
   by 0x804E6FE: myldap_get_entry (myldap.c:1059)
   ...
(the other memory leaks shouldn't grow during execution)

I can reproduce the leak in my test environment when using referrals. I
have not yet narrowed it down to where the allocated memory should be
freed though (perhaps in OpenLDAP code, perhaps in mine).

Perhaps a simple test case should be developed that demonstrates this
leak that could be put forward to the OpenLDAP people.

Sorry this is taking so long.

-- 
-- arthur - arthur@arthurdejong.org - http://arthurdejong.org --

--
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users