Re: (ITS#6437) sl_malloc issues

[h.b.furuseth@usit.uio.no]

hyc@symas.com writes:
> Nobody uses the pool code. I would suggest you profile it against the stack 
> code before spending any time fixing it.

The pool version crashes if I divide SLAP_SLAB_SIZE by 16 or multiply
the allocated amounts by 17.  The stack version stays happy.  I also
tried RE23 and rev 1.48 in case of code rot.  (Should have tried
OpenLDAP 2.2, but would need to install an old Berkeley DB.)  Adding a
sl_malloc fallback to ch_malloc instead of returning NULL didn't help.

Anyway, I tried this because I assume the pool version is intended to
reduce the number of sl_malloc fallbacks to ch_malloc, but that almost
never happens in 'make test' with the current SLAP_SLAB_SIZE.  Which
made that aspect hard to test.

Also the pool version does a number of ch_mallocs for administration and
ch_frees them at reset. If the idea is to reduce ch_mallocs, it should
keep these blocks around.  (Or allocate them with the slab.)  Except the
'slab_object's It only needs cleanup if the slab size changes, which
slapd never seems to do.


-- 
Hallvard