Behaviour change for double-free'ing a pointer

[Joel Sherrill]

Aaron J. Grier wrote:
> On Wed, Dec 19, 2007 at 02:44:15PM -0600, Joel Sherrill wrote:
>   
>> This begs a bigger question... should RTEMS assert at all?
>>     
>
> it raises the question, but doesn't beg it.  begging the question would
> be claiming that RTEMS should assert because it already does.
>
>   
:)  I stop.
>> Most of the asserts I have analyzed over the past couple of months
>> cannot occur unless there is a data corruption problem or problem with
>> the RTEMS internal logic.  Those are being marked with RTEMS_DEBUG
>> conditionals.  Otherwise they are untestable dead code.
>>
>> Should it be possible for RTEMS provided code to halt at run-time?
>>     
>
> assuming RTEMS doesn't have internal logic problems (=, what should
> RTEMS do in the case of data corruption?  for my application, dropping
> back to a bootloader and reloading the system is the safest thing to do,
> so assert() is fine for me.  others may have more complicated
> error-recovery mechanisms, so compile with -DNDEBUG.  it really depends
> on the application, and in the embedded world, there seems to be an
> exception for every rule-of-thumb.
>
>   
FWIW this 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?

--joel