[haiku-development] Re: SLAB documentation

On 2010-07-18 at 22:53:24 [+0200], Lucian Adrian Grijincu 
<lucian.grijincu@xxxxxxxxx> wrote:
> On Sun, Jul 11, 2010 at 12:11 PM, Ingo Weinhold <ingo_weinhold@xxxxxx> 
> wrote:
> > Double free()s could be detected (somewhat expensively) by
> > iterating through the free objects list.
> 
> I was thinking of an implementation that would be more time-efficient,
> but has a space-trade off.
> Only when double-free() checks are in place, each object gains another
> N bytes. These take a values F if the object is free and A if the
> object is allocated.
> If the object has any other value we have a buffer overflow.
> 
> If we try to allocate the object and it's value is A -- somethings
> wrong with the allocator
> If we try to free the object and it's value is F -- the programmer has
> double freed an object.

If additional space is allocated for debugging purposes, one can as well 
implement allocation tracking support. That's what the heap implementation 
does, BTW. I'm sure code could be borrowed.

> Another double free() implementation that doesn't occupy anything, and
> is faster than just iterating through the free list:
> The first N bytes of each object are set to a value F when the object
> is free()d.

This is exactly what the heap implementation does (and what I already 
mentioned in my last mail).

> When an object is freed we look at the object's value. If it's F,
> there may be two causes:
> * double free or
> * the user has set the value F on the first N bytes of the object.
> Increase the size of N and make the value F something more awkward
> (for example, 0, 1, 0xffff would not be very good as these values are
> used a lot).
>
> Because we can't rule each other out, we have to check the free list.
> But if the value of N is big enough and F is awkward enough this
> search should only be done rarely for non-double-free objects.

Well, it's not perfect, since it misses cases where the memory is modified 
after the first free().

> Which do you think is acceptable?

I would implement (respectively port from the heap implementation):

* Full allocation tracking support, which would also detect double-frees. 
Has memory overhead. Should be enabled as separate debug feature (off by 
default).

* Full free list checks. Detects double-frees only. Is relatively 
expensive. Should be enabled as separate debug feature (off by default).

* Free/allocation pattern fills. Have a good chance of tripping code that 
uses freed objects or uninitialized parts of allocated objects. Should be 
enabled at KDEBUG >= 2. Unless allocation tracking or free list checking is 
enabled that should also include the opportunistic double-free check you 
proposed, since it is rather cheap in virtually all cases.

CU, Ingo

Other related posts: