Problem with rtems_task_variable_delete
joel.sherrill at OARcorp.com
Thu Dec 11 12:14:48 UTC 2003
Fernando RUIZ CASAS wrote:
>On Wed, 10 Dec 2003 22:28:48 +0100, 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 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 goal for this is to have a global pointer for an user structure that
>keeps the rootfs dir, curdir, userid, groupid...
>The task var keeps only a pointer for this global/local structure.
>Of course a different solution was pointed by Chris Johns in order to avoid
>the use of task vars because they spend a lot of resources machine in the scheduler.
>But I have designed the telnetd and the shell using only
>the rtems resources availiables.
>The solution pointed by Chris is a best solution.
>Placing the pointer in a task extension slot in lieu of a task var.
That only speeds up the context switch. You still have the possibility
of needing to free
that memory when that task is deleted. When you call free, you would
end up tripping
the same condition.
I also have another patch pending in my tree which moves the call of the
extension to outside a dispatching critical section. That fixes even
>>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.
>>Anyway, whow/where can I get the patches associated with PR523?
>>Thru CVS? Sofar, I've only used the snapshots provided by OAR.
More information about the users