Re: Help: LIBLDAP.DLL makes GPF in ldap_result/ldap_msgdelete

Mark Smith (mcs@umich.edu)
Fri, 09 Feb 1996 10:08:26 -0500

>From: Nils Andreas Thommesen <Nils.Thommesen@kvatro.no>
> To: ldap@umich.edu
>
> When I try to read the attributes of an entry, I can read them with no error.
> But my problem arises at the *next* search, or rather waiting for the results
> of the next search! Can anybody help me? Am I missing some call to LIBLDAP?

Without analyzing your code in detail, my best guess is that you are
corrupting the Windows memory allocator , which eventually causes a GPF
(crash). This is probably due to a misplaced "free" call. A few
things to note:

1. When freeing memory that was allocated by the LIBLDAP.DLL, you
must use the "ldap_memfree()" DLL function rather than the "free()"
library call provided by your development environment.

2. There is no need to call "ldap_msgdelete()". This function is not
documented, and is really only to be used inside the LDAP
library itself. "ldap_msgfree()" is what you want to use.

3. A successful call to "ldap_result()" will place in the "result"
parameter a pointer to an LDAPMessage. This is really a whole
chain of messages in the case of a search operation. You can
free the entire chain just by calling "ldap_msgfree()" once,
passing it the original "result" value.

4. The "ldap_first_entry()" and "ldap_next_entry()" functions do not
allocate any memory that you need to free -- they merely step
through the chain of search entries and result. You should not
include a call like "ldap_msgfree( entry )" if you are calling
"ldap_msgfree( result )" as I describe in 3 above.

I hope this helps -- the U-M LDAP implementors do realize that the
whole question of what to free when using the LDAP libraries is
confusing! Examining the code found in the ldap-3.2/clients/tools
directory or the file ldap-3.2/libraries/libldap/test.c is highly
recommended.

-Mark