[Bug 1246] memory leak: newlib reent struct not cleaned up from libc_delete_hook

[rtems-bugs at rtems.org]

http://www.rtems.org/bugzilla/show_bug.cgi?id=1246





------- Comment #2 from strauman at slac.stanford.edu  2007-08-23 20:21 -------
Created an attachment (id=509)
 --> (http://www.rtems.org/bugzilla/attachment.cgi?id=509&action=view)
fix newlibc's reclaim_reent() [__rtems__ only] so it can be used to plug memory
leak

This (*newlib*) patch fixes __reclaim_reent() [under __rtems__ only] so that it
only releases memory but omits close/seek and other system calls. Such calls
are
illegal at the point during thread deletion when __reclaim_reent() is executed.

Also, the fix is more consistent with RTEMS semantics: __reclaim_reent() now
(i.e., with the fix applied) only releases thread-specific resources but
leaves global ones in place. Consider e.g., the FILE objects representing 
stdin/stdout/stderr. These objects are 'per-thread', i.e., every task has
it's own 3 FILEs and buffers. However, the underlying system file descriptor
is global and may well be shared (e.g., console). When a thread is deleted
then its stdio buffers should be released but the underlying descriptor
must not be closed. These semantics also are more symmetric: at thread
creation,
the system descriptors (0/1/2) are already open; during lifetime of the thread
stdio FILEs/buffers may be created, at deletion the buffers are released
but the system descriptors are left open as they were before the thread
came into 'life'...

NOTE: the companion RTEMS patch is also required (earlier attachment).


-- 
Configure bugmail: http://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.