[Bug 1246] New: memory leak: newlib reent struct not cleaned up from libc_delete_hook
rtems-bugs at rtems.org
rtems-bugs at rtems.org
Thu Jun 14 06:29:36 UTC 2007
http://www.rtems.org/bugzilla/show_bug.cgi?id=1246
Summary: memory leak: newlib reent struct not cleaned up from
libc_delete_hook
Product: RTEMS
Version: 4.7
Platform: All
OS/Version: RTEMS
Status: NEW
Severity: normal
Priority: P3
Component: cpukit
AssignedTo: joel.sherrill at oarcorp.com
ReportedBy: strauman at slac.stanford.edu
This issue was already discussed here
http://www.rtems.com/ml/rtems-users/2004/october/msg00282.html
and here:
http://www.rtems.com/ml/rtems-users/2004/december/msg00004.html
It would be better to use newlibc's __reclaim_reent() routine to cleanup the
reent struct rather than replicating bits of that routine in the
libc_delete_hook(). HOWEVER: newlibc (1.15) stdin/stdout/stderr FILE structs
are
per-thread, not per-process and __reclaim_reent() walks fclose() (calling
fflush()) on those three FILEs. These can be illegal operations since the
device
driver may block in fflush() etc. but the delete_hook is executing from a
dispatch disabled section (and possibly even a different thread context).
A better hack (because it still requires tampering with the reent struct)
than what's currently used would IMO be:
from libc_delete_hook()
set _REENT->stdin->_close = 0;
_REENT->stdin->_seek = 0;
_REENT->stdin->_flags&= ~__SWR;
(same for stdout, stderr) so that the fclose/fflush operation caused
by __reclaim_reent() doesn't cause any device I/O.
eventually, call __reclaim_reent().
Other possibilities (involving newlib patching)
- let newlib implement fpurge() and call prior
to __reclaim_reent() -- still requires avoiding
device close operation.
- create 'rtems_stdio_cleanup' function that does
exactly what fclose does but omits the fflush() and
device close operations. Then attach that 'rtems_stdio_cleanup'
to _REENT->__cleanup
- let stdin/stdout/stderr file structs be per-process rather
than per-thread objects (like all other FILEs) but this would
probably require implementing locking
--
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.
More information about the bugs
mailing list