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

Re: controls state data leakage

Pierangelo Masarati wrote:

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/