From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from forward100o.mail.yandex.net (forward100o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::600]) by sourceware.org (Postfix) with ESMTPS id 66EDA385801D for ; Sun, 13 Dec 2020 12:33:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 66EDA385801D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=yandex.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=hi-angel@yandex.ru Received: from forward100q.mail.yandex.net (forward100q.mail.yandex.net [IPv6:2a02:6b8:c0e:4b:0:640:4012:bb97]) by forward100o.mail.yandex.net (Yandex) with ESMTP id CAC464AC07DA; Sun, 13 Dec 2020 15:33:16 +0300 (MSK) Received: from mxback7q.mail.yandex.net (mxback7q.mail.yandex.net [IPv6:2a02:6b8:c0e:41:0:640:cbbf:d618]) by forward100q.mail.yandex.net (Yandex) with ESMTP id B2BC97080008; Sun, 13 Dec 2020 15:33:16 +0300 (MSK) Received: from vla1-a8b0d5d0127d.qloud-c.yandex.net (vla1-a8b0d5d0127d.qloud-c.yandex.net [2a02:6b8:c0d:d1d:0:640:a8b0:d5d0]) by mxback7q.mail.yandex.net (mxback/Yandex) with ESMTP id fEccIBvT8k-XGIOFLhm; Sun, 13 Dec 2020 15:33:16 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1607862796; bh=HLCDPcDEO2P3Aaa3yjC86/7ybWvxTHMLtcmGDUhNRHk=; h=In-Reply-To:Cc:To:From:Subject:Message-ID:References:Date; b=OKWiutaOQAUF9NSkblO/a6XrFLvNjY5LWlroDQOImZolVWVnNdutvCZusx4zKJZ1T 0TH52DcrYGT1igO8URhTloExz2xSnR3Yq8HUDmXsPXgjaKEa1TC6y2enLUJ+1562Bw /xBGGIkwBnA2BM1/IhZOzOvX/Lxl1DJ0iuDFlmic= Authentication-Results: mxback7q.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by vla1-a8b0d5d0127d.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id oPaM4X3W3s-XGI02NTP; Sun, 13 Dec 2020 15:33:16 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Message-ID: <770f359ad02a553ba8fb3d817f43da6f9fb5d7a2.camel@yandex.ru> Subject: Re: `free` fails to reclaim memory From: Konstantin Kharlamov To: tomas@tuxteam.de Cc: libc-help@sourceware.org Date: Sun, 13 Dec 2020 15:33:14 +0300 In-Reply-To: <20201213115724.GA30670@tuxteam.de> References: <83k0tmeq6f.fsf@gnu.org> <9f49e5542f303736d2e53ce3dc53c1374969e6b4.camel@yandex.ru> <3142ea6128492d89e81c58a3d0f2450f1a583f53.camel@yandex.ru> <20201213115724.GA30670@tuxteam.de> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, 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 X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2020 12:33:20 -0000 On Sun, 2020-12-13 at 12:57 +0100, tomas@tuxteam.de wrote: > On Sun, Dec 13, 2020 at 02:41:06PM +0300, Konstantin Kharlamov wrote: > > Hello, while researching Emacs "leaking memory"¹, we may have actually > > stumbled upon glibc problem: glibc may not return freed memory to the OS, > > and by "memory" I mean here not a few kilobytes or megabytes for the sake of > > cache, but megabytes or even gigabytes. Having researched for a bit, I got > > the following testcase: > > See also [1], especially glibc.malloc.mmap_threshold (default: start > with 128 KB and then adjust dynamically), which decides when to use > mmap (which can be returned to the OS on free) for a chunk, and > glibc.malloc.trim_threshold, which decides the minimum size of frees > (from sbrk) to return to the os (which is set by default at 128 KB) > > So libc's malloc seems to try to do things, perhaps the chunks you > are using in your test program are too small to trigger what you > are expecting. > > Note that if you mix malloc and free, the freed memory is reused, > so your experiment doesn't necessarily explain the "leaking > memory" thing. > > Cheers > > [1] > https://www.gnu.org/software/libc/manual/html_node/Memory-Allocation-Tunables.html >  - t Btw, now that I think of that, I'm wondering: is there any way to figure out how much memory in a running process is used by that glibc-owned memory? I'm interested because I just remember this another bug¹ which also affects me, and nobody knows what exactly takes up that memory out there. Could be the same situation as with Emacs. 1: https://github.com/qutebrowser/qutebrowser/issues/1476