[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Memory leak in ldap_first/next_attribute (ITS#1225)
On Mon, Jul 09, 2001 at 07:31:07AM +0000, johan.andersson@appgate.com wrote:
> Full_Name: Johan Andersson
> Version: 2.0.11
> OS: HPUX
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (193.12.107.226)
>
>
> I am running Purify on a small client program using openLDAP's client library.
> I am iterating over returned attributes in a query with:
>
> char* attr;
> for ( i = 0, attr = ldap_first_attribute( ldap, entry, &ber);
> attr;
> attr = ldap_next_attribute(ldap,entry,ber),i++) { ..... }
>
> The memory that 'attr' points to is leaked.
>
> The docs (on your website:
> http://www.openldap.org/software/man.cgi?query=ldap_first_attribute&sektion=3&apropos=0&manpath=OpenLDAP+2.0-Release
> says the returned 'attr' is to be considered as a static buffer.
>
> However following the source $/libraries/libldap/getattr.c#77/107
> tag = ber_scanf( ber, "{ax}", &attr );
>
> looks like the memory is plainly allocated and just returned. Either the docs
> are wrong
> or you forgot to assign the allocated buffer to some 'connection context'
> somewhere and
> reuse it. Do you agree?
The docs should be updated. This was true for the old API. With the new
API specified in draft-ietf-ldapext-ldap-c-api-05.txt one must call
ldap_memfree on the attribute. Also note the ber_free of the pointer
argument (the last one to next/first_attribute). See appendix A of the
draft for an example.
There is one big problem with this. Applications written for the old API
can compile and work pretty well with the new API, except that there will
be memory leaks.
Stig