[En-Nut-Discussion] NutHeapAlloc Error?

[Timothy M. De Baillie]

Harald Kipp wrote:
> 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!)
>   
I didn't realize the OS was even on SourceForge. I will get on that next 
bug I find.
> 2. hadn't been handled by someone else (yeah, I agree, this heap stuff
> is quite mind boggling)
>   
It was a very deep bug and probably rarely happened to most people. But 
it would happen eventually to just about any project.
> 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.
>   
It's not the prettiest solution but it does fix the bug.
> 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.
>   
I thought of this as well, but didn't implement it because it seemed 
like more work at the time.
> 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.
>   
I agree. It makes sense on the AVR projects, but not the ARM. Either way 
it seems like an arbitrarily unusual 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 agree. It seems rather obvious when you read through that function.
> I very much appreciate your effort on this issue, specifically the time
> you spent on this
No problem. It was time I had to spend anyways.

Tim