More heap corruption / allocator lock problems

[Joel Sherrill]

Till Straumann wrote:

> Hi all.
>
> Paranoia pays off.
>
> Today, (thanks to the paranoia check added to PR#504)
> I found one more place where a CORE_mutex (the allocator
> lock) is acquired from a dispatching-disabled code section:
>
> The task-variable destructor hook (used e.g. by the rtems_shell
> and 'libc userenv')!
>
> Since it is run as part of a user extension's delete
> hook/callback, the task variable destructor runs with
> dispatching disabled :-(
>
> Two solutions come to my mind:
>
> a) memory that is going to be released by a task-variable
>    destructor must be allocated from the workspace

I like this solution and it is where I was heading.  I was thinking of 
adding some
"name wrapper macros" that are like rtems_extension_malloc and 
rtems_extension_free
which are specifically to be used ONLY from the task create and delete 
extensions.


>
> b) free could be enhanced:
>
>    if 'free' is called while _Thread_Dispatch_disable_level > 0,
>    it sends its pointer argument to a special "gc" thread which
>    will eventually execute the real 'free'. The synchronization
>    mechanism *must* be nonblocking, of course, to avoid the
>    same kind of problem...
>
> While I feel that b) is 'hackish', it could certainly provide
> backwards compatibility...

Another simpler approach to this might be to have a list like you suggest
but check that it is non-empty on each malloc or free when 
_Thread_Dispatch_disable_level
is == 0.  It doesn't free memory as quickly as a gc thread would but it 
would get it into
the heap when it matters.

>
> RFC
>
> -- Till
>