Re: Possible bug in __sfp() libc routine

[Freddie Chopin <freddie_chopin at op dot pl>]

On Fri, 2017-04-07 at 21:57 +0000, Kapania, Ashish 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 ?

Hi!

In my understanding newlib just keeps all FILE objects in the
_GLOBAL_REENT but this should not lead to the behaviour you observe.

The objects are indeed shared, which means that they are -
unfortunately - never freed. But on the other hand in your scenario
this should work like this:

1. you start the first thread
2. it tries to open a file
3. __sfp() is called and sees there are no FILE objects, so some are
allocated and the first one is returned
4. when your thread closes the file, its FILE object is kept in
_GLOBAL_REENT, but is marked as free.
5. you start another thread
6. it tries to open a file
7. __sfp() is called, which searches for a free FILE object - it will
find the object which was closed in 4, which will be returned, so
nothing would be allocated
8. same as 4
...

However I must admit that for me the whole design of reentrancy in
newlib is not very consistent and optimal, which causes a lot of memory
to be wasted in a multithreaded application...

Regards,
FCh