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 :

> 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.

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 
#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.

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 :

> 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