Crash/RTEMS internal error on task deletion

[Till Straumann]

Here's a subtle problem (sorry for the long msg):

The current task deletion libc cleanup code
has quite a few problems. Aside from leaking
memory, it has the potential to run the system
into an 'internal error':

The cleanup code currently fclose()s FILEs
other than stdio. This is unsafe, since
the libc_delete_hook runs with thread
dispatching disabled and the device driver
may well use a blocking system call from
'write' (fclose -> fflush -> write; the
termios driver is a candidate) which then
triggers a paranoia assertion in the kernel
(how good we added that assertion a while ago!
[score/include/rtems/score/coremutex.h:176]).

The condition occurs if a thread creates a
FILE and the FILE contains unflushed data
at the time the thread is deleted (thread
doesn't fclose of fflush).

What to do?

Ideally, FILEs are global objects, but newlib-1.11
still treats them per-thread. I suggest:

- we implement/patch newlib's 'cleanup' routine
   to just free all buffers but leave file descriptors
   alone (they are global RTEMS objects anyways).
   Note that any unflushed characters will be lost.
   I don't have a good solution for avoiding this.

- having such a 'cleanup' enables us to use
   reclaim_reent() from the task delete hook
   which would then also do away with the memory leaks
   in a less newlib version dependent way.

RFC
-- Till