From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) by sourceware.org (Postfix) with ESMTPS id 9C74B3858D28 for ; Tue, 12 Apr 2022 16:10:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9C74B3858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embedded-brains.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embedded-brains.de Received: from sslproxy03.your-server.de ([88.198.220.132]) by dedi548.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1neJ6G-000Lsn-GM; Tue, 12 Apr 2022 18:10:40 +0200 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy03.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1neJ6G-000NWe-DT; Tue, 12 Apr 2022 18:10:40 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 1F1C14800A2; Tue, 12 Apr 2022 18:10:40 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 9e2wRG4rYL3i; Tue, 12 Apr 2022 18:10:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id BE5FD48014A; Tue, 12 Apr 2022 18:10:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9ftKfHiaraNc; Tue, 12 Apr 2022 18:10:39 +0200 (CEST) Received: from [10.10.171.14] (unknown [10.10.171.14]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 84FF64800A2; Tue, 12 Apr 2022 18:10:39 +0200 (CEST) Message-ID: <795ccb59-38d3-a9d8-f8d4-9314689d1c62@embedded-brains.de> Date: Tue, 12 Apr 2022 18:10:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH] Fix stdio memory leaks with _REENT_SMALL + _LITE_EXIT Content-Language: en-US To: Volodymyr Medvid , newlib@sourceware.org References: <20220412132313.39160-1-vmedvid@riseup.net> From: Sebastian Huber In-Reply-To: <20220412132313.39160-1-vmedvid@riseup.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.5/26510/Tue Apr 12 10:20:48 2022) X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2022 16:10:46 -0000 On 12/04/2022 15:23, Volodymyr Medvid wrote: > When a thread calls stdio functions (say, printf) and then dies, > _reclaim_reent() runs cleanup_stdio() to free the file buffers > and descriptors created for this thread. This is causing multiple > memory leaks when newlib is configured with _REENT_SMALL > and _LITE_EXIT - this is the standard configuration for > newlib-nano provided with GNU Arm Embedded Toolchain. >=20 > 1. While __sfp() allocates the FILE objects in GLOBAL_REENT glue chain, > stdio_cleanup walks through the thread-specific glue chain > to run the cleanup_func. Therefore, the FILE objects are never > freed. This leaks ~428 bytes per thread (glue_with_file + 3 x FILE)= . Yes, this is the Newlib design. FILE objects are never freed. If you=20 close a FILE object, then it is basically placed on a free list and=20 recycled once another FILE object is opened. >=20 > To fix this, update __sfp() to use the per-thread glue chain for > stdio descriptors. This is definitely not the right way to address this issue. Why don't you use the _REENT_GLOBAL_STDIO_STREAMS Newlib configuration=20 option? >=20 > 2. With _LITE_EXIT enabled, _fflush_r is used as cleanup_func > instead of _fclose_r - as a result, the I/O buffer memory allocated > by __smakebuf_r is never freed - this leaks another 1024 bytes. > To fix this, update cleanup_stdio to always use _fclose_r. >=20 > This is a follow-up patch forhttps://ecos.sourceware.org/ml/newlib/curr= ent/017697.html > --- > newlib/libc/stdio/findfp.c | 9 ++------- > 1 file changed, 2 insertions(+), 7 deletions(-) >=20 > diff --git a/newlib/libc/stdio/findfp.c b/newlib/libc/stdio/findfp.c > index 1370b63b8..2799980f3 100644 > --- a/newlib/libc/stdio/findfp.c > +++ b/newlib/libc/stdio/findfp.c > @@ -153,7 +153,7 @@ __sfp (struct _reent *d) > =20 > if (_GLOBAL_REENT->__cleanup =3D=3D NULL) > __sinit (_GLOBAL_REENT); > - for (g =3D &_GLOBAL_REENT->__sglue;; g =3D g->_next) > + for (g =3D &d->__sglue;; g =3D g->_next) > { > for (fp =3D g->_iobs, n =3D g->_niobs; --n >=3D 0; fp++) > if (fp->_flags =3D=3D 0) This patch would break at least RTEMS. --=20 embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.huber@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht M=C3=BCnchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas= D=C3=B6rfler Unsere Datenschutzerkl=C3=A4rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/