[haiku-development] Re: SLAB documentation
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 18 Jul 2010 23:26:43 +0200
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:
