[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


           Summary: memory leak: newlib reent struct not cleaned up from
           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
and here:

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
per-thread, not per-process and __reclaim_reent() walks fclose() (calling
fflush()) on those three FILEs. These can be illegal operations since the
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