Memory leak after C++ exception

[Valery Pykhtin]

SORRY, SORRY, SORRY,
I did a mistake, just a little nerveous about this bug...

_Internal_error_Occurred indeed called when the task self deletes. Stack 
trace:

#0 _Internal_error_Occurred (INTERNAL_ERROR_CORE, FALSE, 18/* called from 
wrong environment */)
#1 _CORE_mutex_Seize
#2 _API_Mutex_Lock( _RTEMS_Allocator_Mutex )
#3 _RTEMS_Lock_allocator
#4  rtems_region_return_segment
#5  free
#6 _RTEMS_task_Delete_extension
#7 _User_extensions_Thread_delete
#7 _Thread_Close
...
_RTEMS_Lock_allocator, _API_Mutex_Lock, _CORE_mutex_Seize are macros, I put 
it here just for clarity.

_Internal_error_Occurred is called because _Thread_Dispatch_disable_level=1 
in this case, see coremutex.h.

Why _CPU_Fatal_halt in _Internal_error_Occurred doesn't work is another 
issue I will elaborate on it later
(my BSP is pc586).

Valery

> 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
>
>
>