From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70018 invoked by alias); 9 Apr 2017 09:22:50 -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 69977 invoked by uid 89); 9 Apr 2017 09:22:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=cumbersome, HX-Received:Sun, HX-Envelope-From:sk:martin., images X-HELO: mail-pf0-f178.google.com Received: from mail-pf0-f178.google.com (HELO mail-pf0-f178.google.com) (209.85.192.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 09 Apr 2017 09:22:46 +0000 Received: by mail-pf0-f178.google.com with SMTP id s16so20931817pfs.0 for ; Sun, 09 Apr 2017 02:22:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=s3miYo3rj0qlHou/Ca8AjlZn3XME5hYdEAgMtlZi2F0=; b=n+/iPlL/Gs3r6w6+utrRdh7r52btbJPpYIue9ATh+jwBEy8rgzzDR+KvGojAjKhThv B8jV5UmwsCsUxS3V/fwXdIwTeC7At3fWfDS1q7JRmwOSh6GPyZ5ws8NKXv3TucWXTIJe 2KTDgOkRuNYI4bvacQRxh6xrCNY0kqi33MpSmQTbaJptqyUd7Gsqa4D9PHyDz5SYSAr8 hdGmbWvUEY9lcG2sfwcLqdzJVh14tniXCcyrymnuzofaHoqefyyhImX+9wmTsbqHqSYX Kl2vmUX9AvJKpfe6ODPfTJG90AlXfAMxCIhKxO5IwVlGGMU8YOFdRvxuap+Cu230Y9J5 FM2w== X-Gm-Message-State: AFeK/H0tX/oY9tShY2ePdzPv7K5/OLL49YWBdf9rPZuSvkrNnAQ+fwwtRtBT4GagSzmE5gs77fdjcGM7tV7aAw== X-Received: by 10.99.122.78 with SMTP id j14mr49486091pgn.52.1491729765984; Sun, 09 Apr 2017 02:22:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.165.13 with HTTP; Sun, 9 Apr 2017 02:22:45 -0700 (PDT) In-Reply-To: References: From: Martin Velek Date: Sun, 09 Apr 2017 09:22:00 -0000 Message-ID: Subject: Re: Possible bug in __sfp() libc routine To: "Kapania, Ashish" Cc: "newlib@sourceware.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017/txt/msg00290.txt.bz2 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 wrote: > Hi All, > > In the __sfp() function in "libc/findfp.c" file, I see that if no free FI= LE object is found, one is allocated and put on a list in the global re-ent= rancy 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 stru= cture. If I create a thread, do a fopen, do a fwrite (invokes __sfp which i= n 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 re= peatedly, 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 objec= t is not in a list on the local re-entrancy structure, it does not get free= d when I delete the thread and run _reclaim_reent() on the local reentrancy= structure. > > Any thoughts ? > > Best, > Ashish