From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21548 invoked by alias); 11 Apr 2017 11:52:34 -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 20074 invoked by uid 89); 11 Apr 2017 11:52:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,KAM_LAZY_DOMAIN_SECURITY,MISSING_MIMEOLE,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*r:Lisa, H*r:172.20.102, HX-HELO:sk:mailout, H*r:API X-HELO: mailout04.t-online.de Received: from mailout04.t-online.de (HELO mailout04.t-online.de) (194.25.134.18) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 11 Apr 2017 11:52:31 +0000 Received: from fwd23.aul.t-online.de (fwd23.aul.t-online.de [172.20.26.128]) by mailout04.t-online.de (Postfix) with SMTP id E0C7D41B50ED; Tue, 11 Apr 2017 13:52:30 +0200 (CEST) Received: from spica12.aul.t-online.de (rXQ5q+ZXYhNWoEDaMFE5oiqXm89OB9Y7K+0IcH+GbHcfCptCdafpcCVieZP-A5TZUc@[172.20.102.121]) by fwd23.aul.t-online.de with esmtp id 1cxuLV-0X1F7A0; Tue, 11 Apr 2017 13:52:29 +0200 Received: from 195.212.29.186:56544 by cmpweb27.aul.t-online.de with HTTP/1.1 (Lisa V4-8-3-0.13952 on API V5-6-0-0) Received: from 172.20.102.123:28411 by spica12.aul.t-online.de:8080; Tue, 11 Apr 2017 13:52:29 +0200 (MEST) Date: Tue, 11 Apr 2017 11:52:00 -0000 From: "onkel.jack@t-online.de" Reply-To: "onkel.jack@t-online.de" To: "Kapania, Ashish" , Freddie Chopin , "newlib@sourceware.org" Message-ID: <1491911549177.1865859.9a6162c903fa891d8ddb86fef7d34571161854c2@spica.telekom.de> In-Reply-To: References: <1491685449.1218.1.camel@op.pl> Subject: AW: Possible bug in __sfp() libc routine MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017/txt/msg00292.txt.bz2 The described behaviour seems is correct my opinion. File descriptors as well as FILE objects are not bound to a specific thread. In a posix-like environment, file descriptors and related stuff are always = at process scope. Threads are running inside of a process, they share all the resources the p= rocess owns,=20 file descriptors, global variables heap space and so on. Terminating a thread would NOT close files, since they are owned by the pro= cess, not by the thread. It also would make it impossible i.e. use files shared by multiple threads. As far as I have seen in newlib code, the implementation follows these rule= s same way as glibc does. So the correct implementation would be: if a thread does open a file it has= to close it before terminating (or hand it over to another thread who take= care of closing it ....).=20 =20 -----Original-Nachricht----- Betreff: RE: Possible bug in __sfp() libc routine Datum: 2017-04-10T21:53:19+0200 Von: "Kapania, Ashish" An: "Freddie Chopin" , "newlib@sourceware.org" Hi Freddie, The steps you suggested makes sense. The FILE object should be marked as fr= ee on fclose and should be reused the next time around. In my experiments, = it gets reused if I do fopen, fwrite & fclose in a loop. However, when I de= lete the thread and create a new thread to repeat the sequence, the very fi= rst time fwrite is called a new FILE object gets allocated instead of reusi= ng the FILE object created by the now deleted thread. I will step through t= he fwrite & fclose code and try to figure out what is happening. Best, Ashish > -----Original Message----- > From: Freddie Chopin [mailto:freddie_chopin@op.pl] > Sent: Saturday, April 08, 2017 2:04 PM > To: Kapania, Ashish; newlib@sourceware.org > Subject: Re: Possible bug in __sfp() libc routine >=20 > 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 ? >=20 > Hi! >=20 > In my understanding newlib just keeps all FILE objects in the _GLOBAL_REE= NT > but this should not lead to the behaviour you observe. >=20 > 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: >=20 > 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 allo= cated and > the first one is returned 4. when your thread closes the file, its FILE o= bject 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 fin= d the object > which was closed in 4, which will be returned, so nothing would be alloca= ted 8. > same as 4 ... >=20 > 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 waste= d in a > multithreaded application... >=20 > Regards, > FCh =EF=BB=BF