Memory leak after C++ exception
Valery Pykhtin
pykhtin at prosoft.ural.ru
Fri Oct 15 13:59:52 UTC 2004
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
>
>
>
More information about the users
mailing list