Memory leak after C++ exception
Joel Sherrill <joel@OARcorp.com>
joel.sherrill at OARcorp.com
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 OARcorp.com>
* 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
From what I can tell, it would have been fixed in 4.6.0 but not
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
> #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).
>> 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 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
More information about the users