date:20100906

Re: [courier-users] Fwd: Re: Auth daemon memory leak.

2010-09-06 Thread Tom Albers

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 t...@kovoks.nl:

 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 t...@kovoks.nl
 Antwoorden aan:Tom Albers t...@kovoks.nl
  Onderwerp: Re: [courier-users] Auth daemon memory leak.
   Aan: Sam Varshavchik mr...@courier-mta.com

 Quoting Sam Varshavchik mr...@courier-mta.com:

 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

Re: [courier-users] Auth daemon memory leak.

2010-09-06 Thread 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 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.




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] Auth daemon memory leak.

2010-09-06 Thread Tom Albers

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 mr...@courier-mta.com:

 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
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Fwd: Re: Auth daemon memory leak.

Re: [courier-users] Auth daemon memory leak.

Re: [courier-users] Auth daemon memory leak.

3 matches

Site Navigation

Mail list logo

Footer information