newlibc memory leaks (was rtems 4.6.0pre5: memory leak after deleting a task used printf)

[Till Straumann]

Eric Norum wrote:

> Till Straumann wrote:
>
>> Looking into this issue, as always, worms are spilling
>> out of the can...
>>
>> I was trying to see if we could use as much 'newlib' code
>> as possible to cleanup the reent structure after deleting
>> a task. As this should be portable to newer releases of newlib,
>> I also checked on the current status of newlib.
>>
>> It seems that newlib changed recently to maintain 'FILE' objects
>> and 'atexit' handlers on a 'process' rather than 'task' basis
>> (which makes sense, sort of).
>
>
> ?? !!!!
> Does this mean that stdin/stdout/stderr are no longer per-thread 
> values?  If so, how are the FILE data structures protected from race 
> conditions when multiple threads are active in, say, printf?
>
The way it looks (someone more knowledgeable should comment, I only 
peeked...),
stdin/out/err are still per-thread values (one FILE per thread)
- however, the associated 'FILE' objects (like other 'FILE' objects) are 
not part of an
individual thread's context but exist 'globally'. Plus, there is 
protection by locking. I.e.

   thread 1 opens a FILE, pases FILE * to thread 2
   both tasks can write to FILE (lock protection)
   thread 2 continues to use FILE after thread1 dies

There are some subtleties that I don't fully understand at this point 
(also, I was looking
at a snapshot, not a release): every thread seems to have an individual 
set of 'global'
FILE objs for stdio but I can't figure out how these are cleaned up...

T.