Memory leak after C++ exception

Joel Sherrill <> joel.sherrill at
Fri Oct 15 14:17:38 UTC 2004

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

2003-11-26      Joel Sherrill <joel at>

         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


Valery Pykhtin wrote:
> 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_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                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

More information about the users mailing list