Memory leak after C++ exception

[Valery Pykhtin]

Unfortunately, though this patch realy fixes the memory leak, it brings 
another problem:

After the task deletion global variable _System_state_Current becames 
SYSTEM_STATE_FAILED instead of
SYSTEM_STATE_UP. The most strange thing in this that the system continue 
their work. Strange because the only place I have found where 
_System_state_Current changes to SYSTEM_STATE_FAILED is 
_Internal_error_Occurred routine that should abort execution in 
_CPU_Fatal_halt. Setting breakpoints to _Internal_error_Occurred and 
_System_state_Set in debugger gave no results.

I would consider this effect to some exotic memory corruption :(

Valery

>I looked into the RTEMS gthread support implementation
> and I didn't like too much what I saw:
>
> a)  it uses task variables :(
> b)  it leaks memory, indeed. The destructor is never called
>     and the memory allocated for the task variable doesn't seem
>     to be released either (probably not a big problem).
>
> The implementation with task variables is not satisfactory and
> hard to understand. Also, a task variable doesn't behave exactly
> like a gthread key. It isn't created along with a task and doesn't
> die with it (--> if you call gxx_key_delete, there may still
> be threads around using the task variable related to the key).
>
> IMO, it would be desirable to have a few fields in the libc reent
> structure for supporting this kind of things (including 'privateenv'
> and 'rpc context' pointers).
>
> d)  BTW: The gthread_once() implementation could also be improved:
>     It disables task preemption around the callback function
>     which doesn't seem necessary.
>
> ===> I propose an overhaul of cpukit/libcsupport/src/gxx_wrappers.c
>
> -- Till