[Date Prev][Date Next]
> 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
I changed syncrepl to use ch_malloc to suppress those messages for now.