Re: (ITS#3536) ldap_initialize leaks under special conditions

[hyc@symas.com]

 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.

muecketb@sbox.tugraz.at wrote:

>Full_Name: Gernot Stocker
>Version: 2.2.23
>OS: Solaris
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (129.27.145.220)
>
>
>We implemted a self made PAM-Module to authenticate a cyrus imap server against
>a 
>LDAP repository using openldap-libraries for the client connect. Due to the
>dynamic
>nature of a PAM Module it is loaded each time when an authentication is
>performed.
>
>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
>module we 
>reduced the functionality of the module to an ldap_initialize. And still 8k were
>added
>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
>loading 
>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
>solution
>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
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support