Re: controls state data leakage

[Howard Chu <hyc@symas.com>]

Pierangelo Masarati wrote:
> Howard,
>
> I note that controls state data that is stored in o_controls[id] 
> doesn't leak only because it's allocated on the operation's slab.  I 
> noted that for the pagedResults, but it may well occur for other 
> controls.  Was this intended?  Otherwise, we could put in 
> slap_free_ctrls()  a op->o_tmpfree() for each o_controls[i] that is 
> non-zero, unless it's acceptable that controls store there memory that 
> is not allocated with o_tmp* routines.  The other solution is to 
> provide cleanup hooks for each control, and call it, when defined, for 
> all controls that are set.  This solution would be far more general, 
> but it requires som work.
Yes, we should only be using the operation slab here since this data is 
obviously per-operation. An op->o_tmpfree() call would be fine though it 
should be totally unneeded.

After reading thru more papers on alternate malloc implementations and 
threaded designs, as well as playing with some Apache code (memory 
pools) I've been thinking about this some more.
 1) the slab allocator should never fall back to regular malloc; it 
should extend the slab if the current one runs out.
 2) per-operation data allocated on the slab should never need to be 
explicitly freed.
 3) truly temporary data (intermediate storage for some other result, 
most typically dnNormalization work) should be freed when no longer 
needed, and the slab allocator should track and coalesce free blocks.

--
 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/