Behaviour change for double-free'ing a pointer

[Joel Sherrill]

Tim Cussins wrote:
> Hi Joel
>
> On Nov 26th there was a commit that changed the behaviour of free() when
> attempting to free a previously free'd pointer. Before the change, the
> behaviour was to assert(0) - the new behaviour is to printk() a warning
> and continue.
>
> void free(
>   void *ptr
> )
> {
>
>   ...
>
>   if ( !_Protected_heap_Free( &RTEMS_Malloc_Heap, ptr ) ) {
>     printk( "Program heap: free of bad pointer %p -- range %p - %p \n",
>       ptr,
>       RTEMS_Malloc_Heap.start,
>       RTEMS_Malloc_Heap.end
>     );
> }
>
> IMHO the assert method is more correct, as an obvious programmer error
> has been detected and can be caught and a debugger may be attached or
> whatnot.
>   
There is no good answer.  I am sure someone will argue that
there should be no assert's in the normal runtime.  At least
people have vehemently argued that before.  :-D

I'm open to suggestions but asserting or aborting has
been considered bad form in the past.
> I guess there's a good argument for tolerating a double-free - primarily
> that the second free is unlikely to cause disasterous software
> behaviour. Contrast this with assert(), which is undeniably a total
> disaster from a user perspective... :P
>
> Perhaps the choice of behaviour could be based on RTEMS_HEAP_DEBUG?
>
>   
I am trying to eliminate conditional compilation in the heap
related to debug, statistics and dirtying memory.  So it is
a bit early to discuss that.

Every time I got a chance to debug this message being printed,
it turned out a task had blown its stack and clobbered the local
variable it was trying to free.  It's not the only reason it can happen
but that seemed to be the one I always hit.  I almost added more
text to say that but decided there were really too many potential
causes.

--joel
> Regards,
> Tim
>