rtems 4.6.0pre5: memory leak after deleting a task used printf

[Till Straumann]

Aaron J. Grier wrote:

>On Tue, Oct 19, 2004 at 04:35:43PM +0600, Valery Pykhtin wrote:
>  
>
>>#0 __wrap__Heap_Allocate
>>#1 _Region_Allocate_segment
>>#2 rtems_region_get_segment
>>#3 malloc
>>#4 _malloc_r
>>#5 __smakebuf  at newlib/libc/stdio/makebuf.c:81
>>#6 __swsetup at newlib/libc/stdio/wsetup.c:63
>>#7 _vfprintf_r at newlib/libc/stdio/vfprintf.c:519
>>#8 vfprintf at newlib/libc/stdio/vfprintf.c:367
>>#9 printf at newlib/libc/stdio/printf.c:62
>>#10 TestTask
>>    
>>
>
>I've seen similar behavior from within printf and floating point
>handling.  there's a freelist being kept somewhere in the guts of the
>libc reent struct that aren't freed when a task is destroyed, and I
>haven't had the ability/time to track it down.  my current workaround is
>blocking and waking threads instead of creating and destroying them.
>
>one of these days I'll have to track it down and fix it once and for
>all; I just keep getting distracted with actual application code.  (:
>
>  
>
I have a proposed fix for this which seems to work -- no PR filed yet, 
though:

 - call newlib __reclaim_reent() on task deletion
 - never really close fds 0,1,2 unless at system shutdown.
    Make sure, however that associated streams are closed.

It is still open whether FILE streams should be closed at task shutdown
or not. Recent newlib changes seem to implement FILE streams on a
'global' level (making it possible to share FILEs between threads).
It is not clear how to treat 'stdin/out/err' in this scenario, however.

My fix allows for any policy implemented by newlib.

-- T.