Re: [courier-users] Auth daemon memory leak.
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: 1104 Citeren Sam Varshavchik : > 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 > #include > #include > #include > > 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 courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Auth daemon memory leak.
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 #include #include #include 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. pgpo4pJdXiSQX.pgp Description: PGP signature -- 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 courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Fwd: Re: Auth daemon memory leak.
Hi, And my mail refused due to attachment, so I posted it here: http://www.kovoks.nl/authdaemond.log.gz Tom Albers KovoKs B.V. KvK: 1104 Citeren Tom Albers : > Forward to mailing list since I received no reaction yet > > Best, > > Tom Albers > KovoKs B.V. > KvK: 1104 > > > > - Doorgestuurd bericht van t...@kovoks.nl - > Datum: Sat, 14 Aug 2010 23:34:33 +0200 > Van: Tom Albers > Antwoorden aan:Tom Albers > Onderwerp: Re: [courier-users] Auth daemon memory leak. > Aan: Sam Varshavchik > > Quoting Sam Varshavchik : > >> Tom Albers writes: >> >>> Sam, >>> >>> Attached is the logfile. I hope it is useful. >> >> Sorry, I made a small mistake. I forgot that $sbindir/authdaemond is a >> shell wrapper script, not the real binary that ends up running in the >> background. >> >> Please rollback the change, and edit the authdaemond script itself. >> >> Replace >> >> exec ${sbindir}/courierlogger -pid=/var/spool/authdaemon/pid >> $LOGGEROPTS -$1 /usr/libexec/courier-authlib/authdaemond >> >> with >> >> ${sbindir}/courierlogger -pid=/var/spool/authdaemon/pid $LOGGEROPTS -$1 >> valgrind --tool=memcheck --leak-check=yes --log-file=/tmp/authdaemond.log.$$ >> /usr/libexec/courier-authlib/authdaemond & >> >> This is one line. Hopefully this'll do the trick. After starting >> authdaemond and replicating the problem, make a copy of the log file >> before stopping authdaemond. You'll need to stop it by killing the >> process, rather then executing the stop command -- because of the way >> valgrind gets shoved into the pipeline, the regular stop command won't >> work. >> >> By having the pid appended to the generated log filename >> /tmp/authdaemond.log.$$ this will prevent anything useful from being >> overwritten if the wrapper script gets executed again, by mistake. >> >> You can either mail the logs to me, or post it somewhere I can grab if >> my spam filters bounce it, rather than posting the whole thing to the >> list. > > > > Hi, > > Thanks for the help. I had to improvise a bit to get the log, i've > seen that multiple processes has logged in the log unfortunately, but > I hope that's not that crucial for the analysis. > > See attachment. > > Met vriendelijke groet, > > Tom Albers > KovoKs B.V. > KvK: 1104 > > > - > Dit mailtje is verstuurd vanaf de server van KovoKs. > http://www.kovoks.nl > > > > - Einde doorgestuurd bericht - > > > - > Dit mailtje is verstuurd vanaf de server van KovoKs. > http://www.kovoks.nl - 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 courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users