change log for rtems (2011-03-01)
chrisj at rtems.org
Thu Mar 3 02:05:52 UTC 2011
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
> 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
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.
More information about the vc