Problem with rtems_task_variable_delete
Dieter.B.Schaefer at t-online.de
Wed Dec 10 21:28:48 UTC 2003
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)
> -- 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 '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