[Date Prev][Date Next]
Re: (ITS#3536) ldap_initialize leaks under special conditions
From what I've seen, libldap memory leaks are actually due to the
OpenSSL libraries. You can verify this by compiling a version of libldap
without any SSL support and testing a plain ldap connection. Since you
didn't mention the exact versions of SASL or OpenSSL you're using,
there's not much else we can say.
>Full_Name: Gernot Stocker
>Submission from: (NULL) (220.127.116.11)
>We implemted a self made PAM-Module to authenticate a cyrus imap server against
>LDAP repository using openldap-libraries for the client connect. Due to the
>nature of a PAM Module it is loaded each time when an authentication is
>After the module is loaded, an ldap_initialize is called, ldap_bind connects to
>an LDAPS directory and everything is fine. As soon as the authentication is
>done, the module is unloaded by the PAM-internal functions and 8k are left
>behind, increasing the size of the saslauthd.
>Just to make sure that we don't have programmed our own memory leak in the
>reduced the functionality of the module to an ldap_initialize. And still 8k were
>to the calling daemon. Removing the ldap_initialize resulted in a constant size
>of the daemon. That means: it is not a Problem of PAM under Solaris!
>I assume that you reserve some static variables that during normal usage in an
>application are initialized just once and are never freed. But the dynamic
>and unloading bypasses this singleton-behaviour and creats the memory leak.
>We had similar behaviour with SSL initilization during ldap_bind which we could
>avoid by using internal ldap_pvt_tls_destroy() function after the last
>ldap_unbind in the module is performed.
>Do you know about this behaviour? How can we avoid it? ldap_free is not the
>It would be great if there would be just one ldap_shutdown function which frees
>really EVERY variable allocated by the LDAP-library.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support