change log for rtems (2011-03-01)

[Chris Johns]

On 1/03/11 7:26 PM, Sebastian Huber wrote:
> Hello Chris,
>
> your changes are not right.
>
> 	(1) The _Heap_Free() must accept only NULL (which did not work due to a bug in
> _Heap_Protection_block_check_default()) and a valid pointer to an allocated area.
>
> 	(2) The _Heap_Resize_block() must accept only a valid pointer to an allocated
> area.
>
> Does everyone agree with (1) and (2)?
>

Yes to (2) and no to (1). The RTEMS region API call 
rtems_region_return_segment uses the bool result of _Heap_Free to return 
the RTEMS_INVALID_ADDRESS. I think in this API NULL is an invalid 
address so the change I committed is wrong and I need to remove the NULL 
check from _Heap_Free and add to _Workspace_Free.

> Please look at realloc() for an usage of _Heap_Resize_block().

I did. This exposes an interesting issue we have sort of been talking 
about in IRC and off list.

If the pointer passed to realloc is incorrect because it is not mapped 
to the heap's valid memory we return 0 and set errno to a non-standard 
value.

Should a system with such an error attempt to continue when something is 
wrong like it is or should a fatal error be raise using the fatal error 
handler or should this be user controlled ?

The standard states the behavior is undefined which is fair enough. My 
concern is returning NULL misrepresents the state of the system or 
problem and could we do better.

> The heap protection helps to find invalid heap usages.  Like a double-free or a
> free with a pointer to an invalid area.  Thus the checks must be performed
> before the normal heap code.

If there is protection code for the heap I would like it running all the 
time. I know heap calls are expensive so checking would be nice. If I 
run heap protection all the time while developing and testing why not 
leave it on.

If a pointer is returned to the heap that is:

  1) Incorrectly aligned to the alignment allocated, or
  2) Is not a valid heap address (including gaps), or
  3) The block related to the pointer is invalid, or
  4) The block related to the pointer is corrupt

I would like to raise an error.

>
> We have two issues here.
>
> 	(A) _Heap_Free(*, NULL) returns false (debugging disabled).
> 	(B) _Heap_Free(*, NULL) yields an error (debugging enabled).
>
> To address (B) we have to fix _Heap_Protection_block_check_default().

If we had protection on all the time could it handle the in heap check ?

>
> Case (A) is there for a long time.  We should change it to return true.
>

We cannot as per the RTEMS Classic API.

Chris