This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Possible bug in __sfp() libc routine
- From: Martin Velek <martin dot velek at gmail dot com>
- To: "Kapania, Ashish" <akapania at ti dot com>
- Cc: "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Sun, 9 Apr 2017 11:22:45 +0200
- Subject: Re: Possible bug in __sfp() libc routine
- Authentication-results: sourceware.org; auth=none
- References: <C0BBAD24E8CD0E4B8A8BD70B11D9544415CB3BBA@DFLE08.ent.ti.com>
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