RE: Possible bug in __sfp() libc routine

["Kapania, Ashish" <akapania at ti dot com>]

Reviving an old thread...

I recently ran into this issue again where my app was creating and deleting RTOS threads (that do file IO) and that was causing a memory leak. After doing some debugging, I can conclude that there is no bug in __sfp() code but the issue Martin points to in the below email is what I am seeing. Newlib nano does not close the stdio/stdout/stderr descriptors when _reclaim_reent() is called on my RTOS thread's re-entrancy structure. Therefore, every new thread I create ends up allocating a new file descriptor instead of re-using the old ones. To work around this, I am explicitly calling fclose on the thread's stdio/stdout/stderr descriptors in the thread delete hook. I think this should be done in the cleanup function by newlib. Do the maintainers and other newlib experts agree ?

Best,
Ashish

-----Original Message-----
From: Martin Velek [mailto:martin.velek@gmail.com] 
Sent: Sunday, April 9, 2017 2:23 AM
To: Kapania, Ashish
Cc: newlib@sourceware.org
Subject: Re: Possible bug in __sfp() libc routine

What about this thread?

https://sourceware.org/ml/newlib/2015/msg00619.html . I think this issue was not fixed or commented yet.

I have written some info related to newlib, reentrancy
(--enable-newlib-reent-small) and using it in FreeRTOS, however the biggest issue is that it is written in Czech language with no perspective to be translated into English. I have tried translate.google.com and it is somehow cumbersome.
https://support.dce.felk.cvut.cz/mediawiki/images/1/17/Dp_2016_velek_martin.pdf

BR
Martin

On Fri, Apr 7, 2017 at 11:57 PM, Kapania, Ashish <akapania@ti.com> wrote:
> Hi All,
>
> In the __sfp() function in "libc/findfp.c" file, I see that if no free FILE object is found, one is allocated and put on a list in the global re-entrancy structure (_GLOBAL_REENT). This seems like a bug to me. I believe the FILE object should be put on a list in the thread specific reentrancy structure. If I create a thread, do a fopen, do a fwrite (invokes __sfp which in turn allocates the FILE object), do a fclose and then delete the thread, the FILE object allocated by __sfp() is not freed. If a do this sequence repeatedly, I see memory keeps leaking until my app runs out of heap. I have a separate re-entrancy structure for each thread but because the FILE object is not in a list on the local re-entrancy structure, it does not get freed when I delete the thread and run _reclaim_reent() on the local reentrancy structure.
>
> Any thoughts ?
>
> Best,
> Ashish