[Date Prev][Date Next] [Chronological] [Thread] [Top]

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
suggestion above.

>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
TODO list.