Problem with rtems_task_variable_delete

[Joel Sherrill]

Dieter Schaefer wrote:

>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 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
options of:

  + 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 
accomplished.

>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 
with password
guest is what you want.  It should be obvious at that point.  You can 
also get it from CVS
if you want.

>Regards
>Dieter Schaefer
>
>
>
>  
>