Re: Multi-threaded slapd on AIX 4.2.1

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 02:47 PM 7/5/99 +0200, you wrote:
>Good morning OpenLDAP!
>
>I have added some debug code to the malloc (& friends) function. It tends
>to indicate that the memory leak comes from (latest "stable" version) :

A number of memory fixes have been fixed in -devel.  However, as the
changes are somewhat involved and the memory leaks fairly mild I
have hesitate back porting them to 1.2.
 
>- servers/slapd/attr.c line 79
>- servers/slapd/attr.c line 80
>- servers/slapd/value.c line 34
>- libraries/liblber/decode.c line 682
>- libraries/liblber/decode.c line 686

>As I am quite unfamiliar with the OpenLDAP code I wonder if someone could
>tell me if it is a good track to follow or not...

Well, just realize that any fix you suggest will first be applied
to devel.  Hence, when you discover a problem with "stable", it's
often best to code the fix for -devel.  Depending upon the perceived
value vs risk, the change can be back ported to 1.2.

>Is the memory allocated there free()'d in a special way?

In stable, no.
In devel, you need to use the deallocator paired with the allocator.
That is use LBER_FREE() when memory was allocated LBER_MALLOC(),
use LDAP_FREE() when allocated with LDAP_MALLOC().  This pairing
is necessary to support systems with multiple-heap allocations
subsystems.

>Why would this memory leak not appear on other platforms?

The "platform" could be leaking the memory... or inducing an
uncommon failure in OpenLDAP which is leaking the memory... or
just not noticed on other platforms.

>Why does it only show up on a multi-threaded server? ...?

1) the provided threading environment may be poorly implemented,
2) you may be running into one of a few race conditions known
   to exist in "stable" (in preemptive threading environments).
3) a single threaded (or non-preemptive threaded) server will not
   exercise many paths through the code.