[Date Prev][Date Next]
Re: controls state data leakage
Pierangelo Masarati wrote:
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.
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.
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
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/