Problem with rtems_task_variable_delete

[Dieter Schaefer]

Till,
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 '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.

Regards
Dieter Schaefer