Memory leak after C++ exception

[Joel Sherrill <joel@OARcorp.com>]

What RTEMS version is this?  This looks very much like this PR

2003-11-26      Joel Sherrill <joel at OARcorp.com>

         PR 523/filesystem
         * src/malloc.c: Make malloc family safer for use from ISRs and
         dispatching critical sections. If in a critical section while
         doing a free(), then the free is deferred until the next
         malloc() attempt.

 From what I can tell, it would have been fixed in 4.6.0 but not
pre5.

--joel



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


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