Problem with rtems_task_variable_delete
joel.sherrill at OARcorp.com
Thu Dec 11 12:07:54 UTC 2003
Dieter Schaefer wrote:
>thank's for your detailed explanation.
>>As I already pointed out: the task variable destructor is called from a
>>section of code which
>>is protected by 'disabling thread dispatching'. It is ILLEGAL to call
>>'free()' from such a section.
>>_CORE_mutex_Seize() (called indirectly by 'free()' when it acquires the
>>detects the violation and raises 'Internal_error_Occurred()'.
>>PR#504 introduced this safeguard. Prior to PR504 everything would "work"
>>but the heap
>>You must not use 'free' as a task variable dtor (or use the modified
>>'free()' I posted earlier
>>to work around this problem)
>For me, e.g. my programs, it's not a problem at all. If I allocate memory
>I'll free it myself. I don't like to depend on those 'automatic' mechanism.
>(it's a bit different in C++ of course)
I have to wear two hats when I work on RTEMS. On one side, I am a
developer of embedded
real-time applications and have strong opinions about what is proper
style and usage. On the other
side, I have to remember that RTEMS is a tool which can be used by
people with other styles
and that it should be forgiving when possible.
So as an application developer, I agree with you and would pounce
someone who free'd memory
in an ISR in a design review and make them change it.
As RTEMS maintainer, I know we already ahve to detect that mistake and
have the general
+ ignoring it and screwing up the system (current behavior)
+ detecting and explicitly locking up the system,
+ detecting and leaking the memory,
+ dectecting and dealing with it.
I chose a solution that let the system live.
It is common for add-on packages and support libraries to schedule
something to be freed when
a thread is deleted and this allows more flexibility in how that is
>I run into this problem while trying to get telnetd to work.
>telnetd uses the shell, which in turn creates a task variable and a new user
>environment. The use of a task variable in shell is easy to modify in order to
>avoid those problems. (btw, I already did) The other problem comes from
>creating a private environment. shell calles rtems_libio_set_private_env().
>I don't want to go into that and modify it, because I don't see who/what else
>depends on this and what the side effects could be.
>The 'solution' proposed by PR523 is, my opinion, just a patch - not a clean
>solution. My understanding of Realtime Systems is a bit different.
>Why should one call free to release some malloc'ed memory in an interrupt
>service routine? That's just a wrong design, in my opinion.
They shouldn't but a solution which allows memory to be free'd in an
internal RTEMS dispatching
critical section also allows the other behavior.
>Anyway, whow/where can I get the patches associated with PR523?
>Thru CVS? Sofar, I've only used the snapshots provided by OAR.
http://www.rtems.com and click on the "Bug Database". I think guest
guest is what you want. It should be obvious at that point. You can
also get it from CVS
if you want.
More information about the users