Memory leak after C++ exception

[Joel Sherrill <joel@OARcorp.com>]

Valery Pykhtin wrote:
> 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 :(

I don't know why you can't break there but it is considered a fatal
error for Classic API tasks to "fall out" of their main thread
function body.

Do you have a simple example that might be executable on a simulator?
That way it would be easy to check for a generic problem versus an
application specific one.

--joel

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


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985