[En-Nut-Discussion] NutHeapAlloc Error?

[Harald Kipp]

Timothy M. De Baillie wrote:
> Description of Bug:
> If your malloc (NutHeapAlloc) finds the last heap to be the "best" fit
> for your request and it can't be split (there's not enough additional
> space in the heap after the bytes you requested and the heap size and
> DEADBEEF for another "usable" heap), the resulting malloc size can be of
> "odd" (not on 4 byte boundary) size, which causes the malloc to fail
> when the DEADBEEF is written on a non-word boundary.  This results in
> the SAM7 going into ABORT mode, which then the watchdog will catch.

I missed the original thread, but thanks to your reminder about the
upcoming version 4.8, it caught my interest.

Still wondering, why this important issue

1. wasn't in the bug tracker at SourceForge (hint! hint!)
2. hadn't been handled by someone else (yeah, I agree, this heap stuff
is quite mind boggling)

Anyway, let's look into it now, after about 3 months. ;-)

First of all: I agree, that there is a bug with the last node. I do not
fully agree with your solution, although it would fix it.

> //CHANGE, replaced else
>              *fpp = fit->hn_next;
>              fit->hn_size &= 0xfffffffc; //this makes sure we hit a 4
> byte boundary on the DEADBEEF write
>          }
> //end CHANGE

Well, to me this looks like a late fix, which could have been done earlier.

If I got it right, the requested size is always a multiple of 4. The
added overhead is 4, so the final node size will be a multiple of 4 as well.

Thus, the problem will happen only, when the initial heap size is not a
multiple of 4, right? Why not simply take care at NutHeapAdd(), that the
added heap memory is a multiple of 4.

Just one thing disturbed me

#define ALLOC_THRESHOLD 6

which is not a multiple of 4. But it is not really a problem, because it
will not change the allocated size.


> Additional potential bug:
> The malloc isn't checked for available memory after the argument is
> incremented by MEMOVHD.

This is indeed a good idea.

I very much appreciate your effort on this issue, specifically the time
you spent on this.

Harald