From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0.riseup.net (mx0.riseup.net [198.252.153.6]) by sourceware.org (Postfix) with ESMTPS id 54DFC3857B82 for ; Fri, 17 Jun 2022 11:33:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 54DFC3857B82 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=riseup.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=riseup.net Received: from fews1.riseup.net (fews1-pn.riseup.net [10.0.1.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.riseup.net", Issuer "R3" (not verified)) by mx0.riseup.net (Postfix) with ESMTPS id 4LPcP00C6cz9tFs for ; Fri, 17 Jun 2022 11:33:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1655465604; bh=FIorEzEgS3jexPEIVS6ncS25ibNgMP2RlWgoJ0wlpbQ=; h=References:In-Reply-To:From:Date:Subject:To:From; b=RBQaH6avbnN9KQDDRL1YFd9FLtjQOgWOYQ+Ws7K8lzldDGZPWIPCzEB/4hErJorqM WuXzFbIhZACgFPOVCAoFlUtNIRI9PLxB663n5oJAJ3h9FzJOqUDA5yO4pXN1G9TfoE YTeoM5RUk3pJKTqMyFR5qRf20yADiedNpyZXg7z0= X-Riseup-User-ID: DB739A717F4F6DB672E19E683066534958B4F3B2943AE36681593209058FB3F2 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews1.riseup.net (Postfix) with ESMTPSA id 4LPcNz6S2Lz5vfs for ; Fri, 17 Jun 2022 11:33:23 +0000 (UTC) Received: by mail-lj1-f178.google.com with SMTP id b7so4424404ljr.6 for ; Fri, 17 Jun 2022 04:33:23 -0700 (PDT) X-Gm-Message-State: AJIora8295FF4KkTFLloZx5LRnhUlW5/Z4uTpuHHSWsGOjMhEzOpBc5k 2RDe+ZxsNKuw3OiT7iO0AbX+G7eaEshnmi29I0M= X-Google-Smtp-Source: AGRyM1vhgCC4nQhPz0ZeQRbR75JOVpvhnCBcXm5zaZHdXZ3A7b8G+vwmKCAEBQQT31zDj+T4WZeOw4W/DMtJdn9399Q= X-Received: by 2002:a05:651c:1502:b0:255:b837:a27a with SMTP id e2-20020a05651c150200b00255b837a27amr4642103ljf.284.1655465602139; Fri, 17 Jun 2022 04:33:22 -0700 (PDT) MIME-Version: 1.0 References: <20220608094357.12224-1-sebastian.huber@embedded-brains.de> In-Reply-To: From: Volodymyr Medvid Date: Fri, 17 Jun 2022 14:33:10 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] Use global stdio streams for all configurations To: newlib@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Fri, 17 Jun 2022 11:33:30 -0000 On Fri, Jun 10, 2022 at 1:45 PM Corinna Vinschen wrote: > > On Jun 8 11:43, Sebastian Huber wrote: > > The _REENT_GLOBAL_STDIO_STREAMS was introduced by commit > > 668a4c8722090fffd10869dbb15b879651c1370d in 2017. Since then it was enabled by > > default for RTEMS. Recently, the option was enabled for Cygwin which > > previously used an alternative implementation to use global stdio streams. > > > > In Newlib, the stdio streams are defined to thread-specific pointers > > _reent::_stdin, _reent::_stdout and _reent::_stderr. If the option is disabled > > (the default for most systems), then these pointers are initialized to > > thread-specific FILE objects which use file descriptors 0, 1, and 2, > > respectively. There are at least three problems with this: > > > > (1) The thread-specific FILE objects are closed by _reclaim_reent(). This > > leads to problems with language run-time libraries that provide wrappers to > > the C/POSIX stdio streams (for example C++ and Ada), since they use the > > thread-specific FILE objects of the initialization thread. In case the > > initialization thread is deleted, then they use freed memory. > > > > (2) Since thread-specific FILE objects are used with a common output device via > > file descriptors 0, 1 and 2, the locking at FILE object level cannot ensure > > atomicity of the output, e.g. a call to printf(). > > > > (3) There are resource managment issues, see: > > > > https://sourceware.org/pipermail/newlib/2022/019558.html > > > > https://bugs.linaro.org/show_bug.cgi?id=5841 > > > > This patch enables the _REENT_GLOBAL_STDIO_STREAMS behaviour for all Newlib > > configurations and removes the option. This removes a couple of #ifdef blocks. > > --- > > v2: > > > > * Add missing ';' to _REENT_INIT_PTR_ZEROED(). > > > > * Rebase to Newlib master. > > > > newlib/README | 6 -- > > newlib/configure.ac | 10 +-- > > newlib/libc/include/sys/config.h | 7 -- > > newlib/libc/include/sys/reent.h | 118 +++----------------------- > > newlib/libc/reent/impure.c | 6 -- > > newlib/libc/reent/reent.c | 20 ----- > > newlib/libc/stdio/fcloseall.c | 4 - > > newlib/libc/stdio/findfp.c | 53 +----------- > > newlib/libc/stdio/local.h | 17 ---- > > winsup/cygwin/include/cygwin/config.h | 1 - > > 10 files changed, 14 insertions(+), 228 deletions(-) > > LGTM together with your "Fix __fp_lock_all() and __fp_unlock_all()" patch. > > Thx, > Corinna > Hi, I confirmed the memory leak reported as https://sourceware.org/pipermail/newlib/2022/019558.html and https://bugs.linaro.org/show_bug.cgi?id=5841 is no longer observed with this patch - many thanks!