From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dog.birch.relay.mailchannels.net (dog.birch.relay.mailchannels.net [23.83.209.48]) by sourceware.org (Postfix) with ESMTPS id F07A3385701F for ; Sat, 5 Dec 2020 16:48:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F07A3385701F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nadler.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=drn@nadler.com X-Sender-Id: dreamhost|x-authsender|drn@nadler.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 7F62D92159E; Sat, 5 Dec 2020 16:48:18 +0000 (UTC) Received: from pdx1-sub0-mail-a95.g.dreamhost.com (100-98-64-116.trex.outbound.svc.cluster.local [100.98.64.116]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 09BB592118B; Sat, 5 Dec 2020 16:48:18 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|drn@nadler.com Received: from pdx1-sub0-mail-a95.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Sat, 05 Dec 2020 16:48:18 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|drn@nadler.com X-MailChannels-Auth-Id: dreamhost X-Society-Squirrel: 47442f761e2d66f9_1607186898283_589980630 X-MC-Loop-Signature: 1607186898283:323816056 X-MC-Ingress-Time: 1607186898282 Received: from pdx1-sub0-mail-a95.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a95.g.dreamhost.com (Postfix) with ESMTP id B75CB7E607; Sat, 5 Dec 2020 08:48:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=nadler.com; h=subject:to :references:from:message-id:date:mime-version:in-reply-to :content-type; s=nadler.com; bh=CwlldWBNjuYkSBqKc6MEAXjLAh8=; b= CHQciogayk3e6P6gi9JCm0/7F/Ql/pX2HlVBxHNnCoM6yO9GXSXzeJ9hf5aSaVi8 Vyz8lbjpSb5rvcwgE7T50fPG+K1NqWCCtJV8WkrxHk495fsZ0/9yrQlNEh5KXFpc HAco8olx15rLln2NlOkj0vFCceEh1vyGSGfQ1eUeJ24= Received: from [192.168.1.6] (pool-72-74-171-157.bstnma.fios.verizon.net [72.74.171.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: drn@nadler.com) by pdx1-sub0-mail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 908D27E5DC; Sat, 5 Dec 2020 08:48:16 -0800 (PST) Subject: Re: impure_data never reclaimed (unless you add the required cleanup code) To: Fabian Vogt , newlib@sourceware.org References: <3052588.mabWh2cJZc@linux-e202.suse.de> <4717243.TQ9fybG2G6@linux-e202.suse.de> X-DH-BACKEND: pdx1-sub0-mail-a95 From: Dave Nadler Message-ID: Date: Sat, 5 Dec 2020 11:48:14 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <4717243.TQ9fybG2G6@linux-e202.suse.de> Content-Language: en-US X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Sat, 05 Dec 2020 16:48:21 -0000 Apologies Fabian but I'm confused. You say 'operating system', but there is no multi-tasking/threading etc??? In that case, yes, there is exactly one reentrancy structure allocated by newlib, and it can be reused by sequential 'programs'... That reentrancy structure points to storage allocated to support assorted functions within newlib, including dtoa (used within printf'ing a double). Hope that helps, Best Regards, Dave On 12/5/2020 10:58 AM, Fabian Vogt wrote: > Hi, > > Am Samstag, 5. Dezember 2020, 16:48:57 CET schrieb Dave Nadler: >> Hi Fabian - Yes, that is correct, you need that cleanup code. >> However, you must also allocate (and clean up) the reentrancy structure >> for each task/thread. >> FreeRTOS correctly does this on task/thread creation and cleanup (with >> #define configUSE_NEWLIB_REENTRANT 1). >> Hope that helps! > While searching for more info about this I found your related thread on this ML > from some time ago, but I think it's not the same situation. > > newlib/libc/reent/impure.c has: > static struct _reent __ATTRIBUTE_IMPURE_DATA__ impure_data = _REENT_INIT (impure_data); > struct _reent *__ATTRIBUTE_IMPURE_PTR__ _impure_ptr = &impure_data; > > So the struct for the main (without thread support, the only) thread is > allocated statically by newlib. > > It would be possible to do it like FreeRTOS and just allocate a new struct for > _impure_ptr for the main thread, but that would leave impure_data unused and > thus waste space and need more code on top. > > Cheers, > Fabian > >> Best Regards, ,Dave >> >> On 12/5/2020 9:27 AM, Fabian Vogt wrote: >>> Hi, >>> >>> I'm using newlib as libc on top of an OS which provides malloc and free. >>> Threads aren't supported, but programs can be started and stopped. The used >>> heap is shared between all programs, so leaked memory is lost forever. Thus >>> it is important that after a clean exit, every allocation was properly freed. >>> >>> Currently this simple program leaks three allocations though: >>> >>> #include >>> int main() >>> { >>> setbuf(stdout, NULL); // This would be properly freed, avoid distraction >>> printf("This is 0.5 as a float: %f\n", 0.5f); >>> } >>> >>> Those are from Balloc, which allocates a list also for later use. >>> FWICT, _reclaim_reent takes care of freeing the list and its contents, but: >>> - _reclaim_reent is never called for _impure_ptr (== &impure_data) >>> - _reclaim_reent does nothing if impure_ptr is passed >>> >>> Is the OS glue code supposed to do something like this in _exit? >>> >>> struct _reent *global_reent = _impure_ptr; >>> _impure_ptr = NULL; >>> _reclaim_reent(global_reent); >>> >>> With that the leaks are gone, but it seems a bit odd to me. >>> >>> Thanks, >>> Fabian -- Dave Nadler, USA East Coast voice (978) 263-0097, drn@nadler.com, Skype Dave.Nadler1