[Date Prev][Date Next]
Re: [Q] attr.c bug?
At 03:27 PM 6/7/99 -0700, Alex Zeltser wrote:
>Just came across something that seemed strange. I'm doing some testing
>with the NT port of slapd. In attr.c, in attr_syntax_config the variable
>'at' is allocated with a call to ch_calloc. In the case of an error it is
>freed a few lines later with a call to free; in the case of no error, it is
>freed at the end of the function with ldap_memfree (which in turn calls
In slapd, anything allocated with ch_* should be freed with free()...
For NT port (in the short term), I suggest #define free ch_free in
slap.h and implementing a ch_free() in ch_malloc.c. Then modify all ch_malloc() to call ber_mem* functions.
>Looking at implementations of ch_calloc and ber_memfree, it
>appears that the two are not compatible.
Depends on -DLDAP_MEMORY_DEBUG and the platform. Hence the
>It seems ok to call free on a
>ch_calloc'ed ptr, but not ber_memfree. In my case, this triggered an
>assert. Has noone else run into this?
Ignoring LDAP_MEMORY_DEBUG, this behavior is specific to WIN32 and
hence why very few folks have ran into it... I believe ldap_memfree()
was originally invented to help resolve this issue.
>(As another aside, are ch_xalloc functions meant to only be used for
>allocations that _must_ succeed for the program to function properly?
No, they are meant to stop executation due to failure of the caller
to check return values.
>They all see to call 'exit' on allocation failures which seems a bit extreme
>under normal conditions.)
I concur... better memory allocation fault handling is on the