(ITS#3536) ldap_initialize leaks under special conditions

[muecketb@sbox.tugraz.at]

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.