Thanks. The mem leak you talked about was in 2002 I think.
But in recent versions there are also mem leaks reported, see second item on: http://www.openldap.org/software/release/changes.html I've upgraded from 2.4.17 to 2.4.23, and the it looks a lot better in the first 15 minutes. I'll confirm tomorrow evening. Again thanks for the quick analysis. Best, Tom Albers KovoKs B.V. KvK: 11033334 Citeren Sam Varshavchik <[email protected]>: > Tom Albers writes: > >> Hi, >> >> And my mail refused due to attachment, so I posted it here: >> http://www.kovoks.nl/authdaemond.log.gz > > This appears to show that your LDAP library is leaking memory, internally: > > ==15156== 33,195 (332 direct, 32,863 indirect) bytes in 1 blocks are > definitely lost in loss record 161 of 163 > ==15156== at 0x4022F8B: calloc (vg_replace_malloc.c:418) > ==15156== by 0x467307B: ber_memcalloc_x (in /usr/lib/liblber-2.4.so.2.5.0) > ==15156== by 0x46359B3: ldap_create (in /usr/lib/libldap_r-2.4.so.2.5.0) > ==15156== by 0x463608D: ldap_initialize (in > /usr/lib/libldap_r-2.4.so.2.5.0) > ==15156== by 0x460E7EB: ??? > ==15156== by 0x460F9B8: ??? > ==15156== by 0x460FDF0: ??? > ==15156== by 0x461056F: ??? > ==15156== by 0x4111844: getpwnam_r@@GLIBC_2.1.2 (getXXbyYY_r.c:253) > ==15156== by 0x41112AE: getpwnam (getXXbyYY.c:117) > ==15156== by 0x4028F65: ??? (in /usr/lib/courier-authlib/libauthpam.so) > ==15156== by 0x4028AC7: ??? (in /usr/lib/courier-authlib/libauthpam.so) > ==15156== ==15156== 33,195 (332 direct, 32,863 indirect) bytes in 1 > blocks are definitely lost in loss record 162 of 163 > ==15156== at 0x4022F8B: calloc (vg_replace_malloc.c:418) > ==15156== by 0x467307B: ber_memcalloc_x (in /usr/lib/liblber-2.4.so.2.5.0) > ==15156== by 0x46359B3: ldap_create (in /usr/lib/libldap_r-2.4.so.2.5.0) > ==15156== by 0x463608D: ldap_initialize (in > /usr/lib/libldap_r-2.4.so.2.5.0) > ==15156== by 0x460E7EB: ??? > ==15156== by 0x460F9B8: ??? > ==15156== by 0x460FDF0: ??? > ==15156== by 0x461056F: ??? > ==15156== by 0x4111844: getpwnam_r@@GLIBC_2.1.2 (getXXbyYY_r.c:253) > ==15156== by 0x45CF98A: pam_modutil_getpwnam (in /lib/libpam.so.0.82.2) > ==15156== by 0x4918AFB: ??? (in /lib/security/pam_unix.so) > ==15156== by 0x4918BF0: ??? (in /lib/security/pam_unix.so) > ==15156== ==15156== 33,376 (332 direct, 33,044 indirect) bytes in 1 > blocks are definitely lost in loss record 163 of 163 > ==15156== at 0x4022F8B: calloc (vg_replace_malloc.c:418) > ==15156== by 0x467307B: ber_memcalloc_x (in /usr/lib/liblber-2.4.so.2.5.0) > ==15156== by 0x46359B3: ldap_create (in /usr/lib/libldap_r-2.4.so.2.5.0) > ==15156== by 0x463608D: ldap_initialize (in > /usr/lib/libldap_r-2.4.so.2.5.0) > ==15156== by 0x460E7EB: ??? > ==15156== by 0x460EDAC: ??? > ==15156== by 0x460FAA4: ??? > ==15156== by 0x460FDF0: ??? > ==15156== by 0x461056F: ??? > ==15156== by 0x4111844: getpwnam_r@@GLIBC_2.1.2 (getXXbyYY_r.c:253) > ==15156== by 0x45CF98A: pam_modutil_getpwnam (in /lib/libpam.so.0.82.2) > ==15156== by 0x4918AFB: ??? (in /lib/security/pam_unix.so) > > Google shows that there was a documented memory leak in > ldap_initialize() in old versions of OpenLDAP. > > To test this theory, compile the following short test program: > > #include <ldap.h> > #include <lber.h> > #include <string.h> > #include <stdio.h> > > int main() > { > LDAP *ldapfp; > struct berval cred; > > while (1) > { > ldap_initialize(&ldapfp, "ldap://localhost";); > > cred.bv_val=(char *)"bindpassword"; > cred.bv_len=strlen(cred.bv_val); > > if (ldap_sasl_bind_s(ldapfp, "binddn", NULL, &cred, NULL, NULL, > NULL) > != LDAP_SUCCESS) > { > printf("Simple bind failed\n"); > } > > ldap_unbind_ext(ldapfp, NULL, NULL); > } > } > > Put in the LDAP url, the bind dn and password from your authldaprc into > the corresponding places in here, cc -o testprog testprog.c -lldap. Run > it, and see with ps if this is leaking memory. If so, you'll need to > upgrade your LDAP library. ------------------------------------------------- Dit mailtje is verstuurd vanaf de server van KovoKs. http://www.kovoks.nl ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
