Behaviour change for double-free'ing a pointer

[Kenneth J. Peters]

>On Thu, Dec 20, 2007 at 01:05:03PM -0600, Joel Sherrill wrote:
>>  Aaron J. Grier wrote:
>>
>>  FWIW [double-free] isn't an RTEMS internal error.  It is a case where
>>  the user called free with a bad pointer.
>>
>>  + Not in the heap
>>  + already freed
>>  + not the starting address of a block
>>
>>  In all cases, RTEMS does not cause a fatal error when the user makes
>>  an API call with bad arguments.  If we think "free of bad pointer" is
>>  a common enough case that it should be a place where a user can plug
>>  in a handler, then that's OK.
>>
>>  >I believe it should be possible and optional for RTEMS to halt at
>>  >run-time.
>>
>>  In this case only or do you have a set of these in mind?
>
>I think the existing RTEMS_DEBUG and consistency checks covers the other
>cases.
>
>since I am RAM constrained, having hooks to catch bad malloc/free usage,
>heap corruption, and stack overflows have been helpful to me in the
>past.  I'd hate to see them be removed because "failed API calls should
>not halt the machine."  there are cases where both behaviors are
>helpful.
>

Couldn't a hook be created for the user to provide the "assert" 
function/macro that RTEMS calls internally (ideally with an 
RTEMS-provided default if the user does not provide one)? I have seen 
other systems (for example, the Quantum Platform) where that is the 
case. Then in theory the user could either compile out all assert 
calls for efficiency (if you keep the conditional compilation), or 
provide their own halting assert, or provide a non-halting assert if 
they had something special to do instead. Don't forget that some 
systems may not have a "printk" that does anything (poor bastards...)