More heap corruption / allocator lock problems

[Till Straumann]

I implemented a quick workaround for this which can simply
be linked to an existing application using the

-Wl,--wrap,free

gcc/linker option. See attached file

-- T.

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
> 
> 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...
> 
> RFC
> 
> -- Till
> 

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gc.cc
URL: <http://lists.rtems.org/pipermail/users/attachments/20031008/745b044f/attachment-0001.ksh>