Re: slap_sl_malloc

["Jong-Hyuk" <jongchoi@OpenLDAP.org>]

> While I would hate to slow this thing down, it appears we may need to 
> use a smarter algorithm here. Currently sl_malloc acts like a stack, 
> objects must be freed in reverse order of allocation otherwise they 
> remain allocated. I'm seeing a lot of "sl_malloc of XX bytes failed, 
> using ch_malloc" log messages while watching syncrepl do its thing, 
> which implies that there is a leak, or objects are not being freed in 
> the correct order.
> 
> I'm not entirely sure there's a leak. But it's very likely that things 
> aren't being freed in order, and it's difficult to verify a proper order 
> now. Which implies that we maybe want sl_malloc/sl_free to keep a free 
> list, coalesce blocks, etc., etc. - all the things a real malloc routine 
> does.

I changed syncrepl to use ch_malloc to suppress those messages for now.