Problem with rtems_task_variable_delete

[Joel Sherrill]

Till Straumann wrote:

> RTM (see below)
> 
> 
> Dieter.B.Schaefer at t-online.de wrote:
> 
>>> On Tue, 09 Dec 2003 01:18:32 -0800 (PST), "Fernando RUIZ CASAS" wrote:
>>>
>>> After browsing in the versions of sources the problem was fixed.
>>>
>>>
>>> http://www.rtems.com/cgi-bin/cvsweb.cgi/rtems/cpukit/rtems/src/tasks.c.diff?r1=1.34&r2=1.35 
>>>
>>>
>>> In tasks.c the problem can be isolated again.
>>>
>>> while (tvp) {       next = tvp->next;          if  (tvp->dtor)     
>>>         (*tvp->dtor)( tvp->ptr ); <<< HERE the change and the source 
>>> of the problem.              if (executing == deleted)              
>>> *tvp->ptr = tvp->gval;              _Workspace_Free( tvp );     
>>> Some printk let to show the dtor, the ptr, and more...
>>> I can't test it. Sorry.
>>>
>>>   
>>
>>
>> Thank's for the hint. I had already modified this before. 
>> Unfortunately, it's not the solution. Here is what happens ... 
>> free(...) is called with the correct value |-> calles 
>> rtems_region_return_segment(...)
>>                |-> calles _RTEMS_Lock_allocator()
>>                                |-> calles _Internal_error_Occured(...)
>>                                               |-> calles 
>> _BSP_Fatal_error(...)
>> -> the end of the world.
>> Any ideas, any hints from RTEMS professionals?
>>
> 
> 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)

PR523 adds a deferred free list.  If in an interrupt or critical
section, the freed memory is added to a list which is freed at the
next call to malloc.  This is the simplest solution which doesn't
add a GC thread.  It does defer the cost of free to the next allocation
which is probably in another thread.  That's skews some CPU time but
it is consistent in that all memory that would have been freed before
the malloc is attempted will in fact be freed.  So from a user's
perspective of sequencing malloc and free, it is the same.

> HTH
> 
> -- Till
> 
> PS: You guys might want to read the threads
> 
>         'Possible bug in _CORE_mutex_Seize()' discussed around 2003/9/30
> 
>       and
> 
>          'More heap corruption / allocator lock problems' discussed 
> aroung 2003/10/7
> 
>>
>> BTW, did someone manage to run *all* spxx tests on a mbx8xx board 
>> successfully? Would be interesting to know if they all work with the 
>> unmodified BSP supplied in the source tree (rtems-4.6.0pre5)
>>
>> Regards
>> Dieter Schaefer
>>
>>
>>
>>  
>>
> 
> 
> 


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985