memory leak: newlib reent struct not cleaned up from libc_delete_hook

[strauman]

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

[strauman]

Fix memory leak; use newlibc reclaim_reent.

[strauman]

fix newlibc's reclaim_reent() [rtems only] so it can be used to plug memory leak

[Sebastian Huber]

Fixed with Newlib 2.1.0, see also libtests/newlib01.

[Gedare Bloom]

Replace Version=HEAD with Version=4.11 for the tickets with Milestone >= 4.11