From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: DJ Delorie Newsgroups: gmane.emacs.bugs Subject: bug#45200: [PATCH] Force Glibc to free the memory freed Date: Wed, 03 Feb 2021 15:51:51 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40884"; mail-complaints-to="usenet@ciao.gmane.io" Cc: carlos@redhat.com, fweimer@redhat.com, 45200@debbugs.gnu.org, monnier@iro.umontreal.ca To: Konstantin Kharlamov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 03 21:53:29 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l7P9V-000AYN-0d for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Feb 2021 21:53:29 +0100 Original-Received: from localhost ([::1]:36022 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l7P9T-0002f8-Sy for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Feb 2021 15:53:27 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38138) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l7P9A-0002ee-58 for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2021 15:53:08 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55675) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l7P93-0006jK-OJ for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2021 15:53:07 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l7P93-000470-M6 for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2021 15:53:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: DJ Delorie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Feb 2021 20:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45200 X-GNU-PR-Package: emacs Original-Received: via spool by 45200-submit@debbugs.gnu.org id=B45200.161238552515743 (code B ref 45200); Wed, 03 Feb 2021 20:53:01 +0000 Original-Received: (at 45200) by debbugs.gnu.org; 3 Feb 2021 20:52:05 +0000 Original-Received: from localhost ([127.0.0.1]:38988 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l7P89-00045r-3U for submit@debbugs.gnu.org; Wed, 03 Feb 2021 15:52:05 -0500 Original-Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:45066) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l7P86-00045M-59 for 45200@debbugs.gnu.org; Wed, 03 Feb 2021 15:52:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612385521; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to; bh=iQmEUX6iyTFyLxtE39ggwxhxca4iQpyLHe+ss4nTJ5A=; b=GHdYc16nGgQQon0u4oQ4bOpHGvi0l/bf1MxYEcXp10srMg2RMFJOqnLXUc0ew5CD39A75B d+gjXNPy6RUNkdWeBN+ETuvw6Nun/PNWaqMYSw//mg/9qABp2/LS2TwOul0PP3jinJxR3G ZptydP30pQMrf2DkQB8SQxtmdvk7uvw= Original-Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-534-atzrEJ5jPpufJCqsiL9LEg-1; Wed, 03 Feb 2021 15:51:58 -0500 X-MC-Unique: atzrEJ5jPpufJCqsiL9LEg-1 Original-Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CBFD9100CCC2; Wed, 3 Feb 2021 20:51:56 +0000 (UTC) Original-Received: from greed.delorie.com (ovpn-114-77.rdu2.redhat.com [10.10.114.77]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9EA915D9F6; Wed, 3 Feb 2021 20:51:53 +0000 (UTC) Original-Received: from greed.delorie.com.redhat.com (localhost [127.0.0.1]) by greed.delorie.com (8.14.7/8.14.7) with ESMTP id 113KppHg001856; Wed, 3 Feb 2021 15:51:52 -0500 In-Reply-To: <542372cc86c88931a80574dd61c5342023424cca.camel@yandex.ru> (message from Konstantin Kharlamov on Wed, 03 Feb 2021 23:28:54 +0300) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dj@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:199246 Archived-At: Konstantin Kharlamov writes: > =CE=B1) sometimes, call to `free()` frees memory completely > =CE=B2) sometimes, call to `free()` leaves memory lingering forever, till= malloc_trim is called additionally. > > The answer I'd like to know is why do you not do always either =CE=B1 or > always =CE=B2? (I'm leaving out here the question of which way is correct > and why, I'm rather curious just why the difference in behavior). If the chunk being free'd happens to be the highest-addressed chunk in the heap, it "exposes" that hole in the heap below it, if that exceeds MALLOC_TRIM_THRESHOLD it causes a trim. If the chunk is *not* at the top of the heap, nothing happens. We only trim the top of the heap. Of course, this assumes that the caching logic doesn't decide to hold on to the chunk *anyway* (like, if it's put in tcache), in which case it's not freed despite being at the top of the heap. Note that any patch affecting tcache performance will need to be vigorously defended ;-) IIRC the fastbin cache also holds onto the top chunk. Since trimming cleans the fastbin, this often frees the top chunk. Disabling fastbins might be an interesting thing to try.