newlibc memory leaks (was rtems 4.6.0pre5: memory leak after deleting a task used printf)
strauman at slac.stanford.edu
Thu Oct 21 16:15:43 UTC 2004
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
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...
More information about the users