From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5149 invoked by alias); 8 Apr 2017 21:04:18 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 5130 invoked by uid 89); 8 Apr 2017 21:04:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:C0BBAD2, H*i:sk:C0BBAD2, H*F:D*pl X-HELO: smtpo59.poczta.onet.pl Received: from smtpo59.poczta.onet.pl (HELO smtpo59.poczta.onet.pl) (213.180.142.190) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 08 Apr 2017 21:04:14 +0000 Received: from [192.168.2.253] (213-238-94-101.adsl.inetia.pl [213.238.94.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: freddie_chopin@op.pl) by smtp.poczta.onet.pl (Onet) with ESMTPSA id 3w0ppf0zPLzlk0TD; Sat, 8 Apr 2017 23:04:09 +0200 (CEST) Message-ID: <1491685449.1218.1.camel@op.pl> Subject: Re: Possible bug in __sfp() libc routine From: Freddie Chopin To: "Kapania, Ashish" , "newlib@sourceware.org" Date: Sat, 08 Apr 2017 21:04:00 -0000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017/txt/msg00289.txt.bz2 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