[Date Prev][Date Next]
Re: Tim Howes' 03.1.c: ldap_memfree/ber_free crashes
At 03:13 PM 6/7/99 +0100, Dr. Rich Artym wrote:
>I would expect this to be a FAQ since it concerns the very first program in
>Tim Howes' book, but searches in the 6 mailing list archives don't suggest
>that there is any all-encompassing problem with the *free functions so I'm
>probably doing something wrong at this end.
The examples in the Howes' bookS are targetted at the Netscape SDK.
The Netscape SDK has significantly different from the U-Mich API
which OpenLDAP 1.x is compatible with. Hence, you will have to
make a number of changes to these examples to get them to work
under OpenLDAP 1.x (which uses a Umich 3.3 compatible API).
The most difficult task is reworking memory allocation to be
compatible with Umich 3.3 APIs.
>In a nutshell, the only way I can get Tim Howes' program 03.1.c to
>compile and link against OpenLDAP 1.2.3 and then to run without
>crashing is by defining out or removing all the calls to ldap_memfree()
Yes, this "quick fix" works. U-Mich API doesn't have ldap_memfree()
(except on some platforms that have multiple memory allocation
heaps, ie: WIN32).
>This could be related to some items in the bugs list concerning
>ldap_memfree. Since this function doesn't appear to be present in
>OpenLDAP 1.2.3, I followed the advice I found there and #defined
>ldap_memfree() to use free().
Unfortunately, it's not that simple. You need to change some to
free(), make some conditional on results, and remove others.
For simple, short-living programs; the "quick fix" is probably
best... or at least until you have time to understand the
subtle differences between the APIs.
I recommend you read the Appendix D, "Known Incompatibilities
with RFC1823" of the IETF C LDAP API draft. The draft is
available at http://www.ietf.org/. Netscape SDK memory
handling is similiar to this draft, U-Mich API is similiar to
RFC1823. You may also want to search Netscape's devedge
site. They might have U-Mich -> Netscape porting document
which might help (you'd use it in reverse).
OpenLDAP 2.0 SDK will be adhere closily to the IETF draft spec
(hopefully both will be completed soon). You might want
to toy around with OpenLDAP-devel (bleeding edge code),
it's API is quite similiar to the IETF draft spec (though
not yet LDAPv3).