This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Possible bug in __sfp() libc routine


Slight correction in my previous email. __sfp() is in "libc/stdio/findfp.c" not "libc/findfp.c".

> -----Original Message-----
> From: Kapania, Ashish
> Sent: Friday, April 07, 2017 2:58 PM
> To: newlib@sourceware.org
> Subject: Possible bug in __sfp() libc routine
> 
> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]