Problem with rtems_task_variable_delete
Fernando RUIZ CASAS
correo at fernando-ruiz.com
Thu Dec 11 09:16:58 UTC 2003
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
> > allocator lock)
> > detects the violation and raises 'Internal_error_Occurred()'.
> > PR#504 introduced this safeguard. Prior to PR504 everything would "work"
> > but the heap
> > was corrupted!
> > You must not use 'free' as a task variable dtor (or use the modified
> > 'free()' I posted earlier
> > to work around this problem)
> > HTH
> > -- Till
> 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.
> 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.
> Dieter Schaefer
More information about the users