Received: (at 81087-done) by debbugs.gnu.org; 6 Jun 2026 09:32:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 06 05:32:23 2026 Received: from localhost ([127.0.0.1]:36105 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1wVnOB-0008G0-23 for submit <at> debbugs.gnu.org; Sat, 06 Jun 2026 05:32:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34508) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1wVnO9-0008Fc-FZ for 81087-done <at> debbugs.gnu.org; Sat, 06 Jun 2026 05:32:21 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1wVnO4-00068s-6Z; Sat, 06 Jun 2026 05:32:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=SXXHxII1EHpYBn4z62FkxFFFn8cZsx2cGpq7zRjndVs=; b=VxD7GpW658KS FwM7VRoHe1vNHf8kWviy1Ole8tU1hOHlzrNxjLycQ4dCosKI6whNgJ1aLLBlZQSLMlcr0HHLAaAPP U8rralyQ49KHvmkvX+tdb4NzWMEY1TG/hhb7SLpJAkg6a52xn2ZQF4Xa7z/KtoQk3oHmwktK6GxvK iVnJD8uy0lOV4xq956IV01MLkte1hiN563iNETFyuZDm8V90tgJRxiYvPVXg20EreemWIms+ZAW2a 49GyDQRC/wJco318uqQP2bbgwIvpj2+ASK1kZzkl74JkviCovGWQWvm73ZdnZBoS2zHIkDLsLvexN DeN9xYd9fmOkaKUHmi8hvg==; Date: Sat, 06 Jun 2026 12:32:13 +0300 Message-Id: <86mrx8ko9u.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: eric.auld@HIDDEN In-Reply-To: <86ecj5z1u8.fsf@HIDDEN> (message from Eli Zaretskii on Thu, 21 May 2026 09:57:51 +0300) Subject: Re: bug#81087: Emacs 30.2 on macOS retains ~500 MB RSS after closing most buffers References: <CAJoW6jc0FO20F5rigxFvVvAYHso=ihKHh34Tvx50SGmCiDx8cA@HIDDEN> <86ecj5z1u8.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 81087-done Cc: 81087-done <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: 81087 <at> debbugs.gnu.org > Date: Thu, 21 May 2026 09:57:51 +0300 > From: Eli Zaretskii <eliz@HIDDEN> > > > From: Eric Auld <eric.auld@HIDDEN> > > Date: Wed, 20 May 2026 18:31:42 -0400 > > > > The concern is not that 500 MB RSS is necessarily impossible for Emacs, but > > that the footprint remained high after reducing the number of open buffers > > substantially. This makes it look not simply explained by having many buffers > > open. > > The question is how much of that memory is "free" for using by the > Emacs process. Many C runtime libraries don't return memory to the OS > but retain it as part of the process's address space as free blocks. > So if you want to know whether there is indeed some problem, you need > to use some tool that can show how much of that memory footprint is > allocated and how much is free blocks. No further comments within more than 2 weeks, so I'm now closing this bug.
Eric Auld <eric.auld@HIDDEN>:Eli Zaretskii <eliz@HIDDEN>:Received: (at 81087) by debbugs.gnu.org; 21 May 2026 06:58:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 21 02:58:06 2026 Received: from localhost ([127.0.0.1]:34662 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1wPxM3-0000pz-R0 for submit <at> debbugs.gnu.org; Thu, 21 May 2026 02:58:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56778) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1wPxLz-0000o6-OP for 81087 <at> debbugs.gnu.org; Thu, 21 May 2026 02:58:01 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1wPxLu-00011p-B8; Thu, 21 May 2026 02:57:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=XUp+OUq2JIIlyRT6Nb6U5N29nQ8OhbGiMefXoWfz4Oc=; b=c7XtiMWDw6k9 56WtjxK7zuMIFWLHyvPn+Tpk+VE5HYgj7d2tSsDaVMUziIBkYLDDak8ZXVtIr7X1YQ5TezQFh8Qfj zvIAxHDHR7fBoHuCuEGBWZgwFrAf5ScdznSVt0atPrr+YGLBSnSNwHTyqz45k1+Xikloto8Un4bGy gDdG3W5EyyWQWXa2QnZn9bpZ5XHnImB2umoylE6fKKlBzwv7j80Ub2VKqy77ZmlAmyFYJ+hTHdckk Ki+4k8v/AUvVzJOWbonta4sldo3O1KRbHYd6R0gu/j5Is97WjtCE7XXJd+ycxiIhg2o/yg1cKzfL0 MlD+LyHug8aVXWKI8BJSGw==; Date: Thu, 21 May 2026 09:57:51 +0300 Message-Id: <86ecj5z1u8.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Eric Auld <eric.auld@HIDDEN> In-Reply-To: <CAJoW6jc0FO20F5rigxFvVvAYHso=ihKHh34Tvx50SGmCiDx8cA@HIDDEN> (message from Eric Auld on Wed, 20 May 2026 18:31:42 -0400) Subject: Re: bug#81087: Emacs 30.2 on macOS retains ~500 MB RSS after closing most buffers References: <CAJoW6jc0FO20F5rigxFvVvAYHso=ihKHh34Tvx50SGmCiDx8cA@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 81087 Cc: 81087 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Eric Auld <eric.auld@HIDDEN> > Date: Wed, 20 May 2026 18:31:42 -0400 > > The concern is not that 500 MB RSS is necessarily impossible for Emacs, but > that the footprint remained high after reducing the number of open buffers > substantially. This makes it look not simply explained by having many buffers > open. The question is how much of that memory is "free" for using by the Emacs process. Many C runtime libraries don't return memory to the OS but retain it as part of the process's address space as free blocks. So if you want to know whether there is indeed some problem, you need to use some tool that can show how much of that memory footprint is allocated and how much is free blocks.
bug-gnu-emacs@HIDDEN:bug#81087; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 21 May 2026 05:13:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 21 01:13:43 2026
Received: from localhost ([127.0.0.1]:34002 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1wPvj3-0008N4-J0
for submit <at> debbugs.gnu.org; Thu, 21 May 2026 01:13:42 -0400
Received: from lists1p.gnu.org ([2001:470:142::17]:39602)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eric.auld@HIDDEN>)
id 1wPpSe-0003EJ-G9
for submit <at> debbugs.gnu.org; Wed, 20 May 2026 18:32:21 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eric.auld@HIDDEN>)
id 1wPpSY-0000GP-FY
for bug-gnu-emacs@HIDDEN; Wed, 20 May 2026 18:32:14 -0400
Received: from mail-dl1-x122b.google.com ([2607:f8b0:4864:20::122b])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from <eric.auld@HIDDEN>)
id 1wPpSW-0003LW-Ki
for bug-gnu-emacs@HIDDEN; Wed, 20 May 2026 18:32:14 -0400
Received: by mail-dl1-x122b.google.com with SMTP id
a92af1059eb24-135e88b8e55so5138593c88.0
for <bug-gnu-emacs@HIDDEN>; Wed, 20 May 2026 15:32:11 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1779316330; cv=none;
d=google.com; s=arc-20240605;
b=OwAuqsHS8/6NSGCus9pBdUhPK/f5W/64Ju1KGEV8LOMONNr6p8toeWJ23S8xLEEutA
pSsTzxwy3N43NDVP8zIYV3wdeGeraYAetHvvYeAnVKpIDN5viGb9EIW+daHqU1k1ywP6
I6RnpzAj1KeDo8cDG4gvN9VFQjvIjud01L2Z5wgIIGM98DsWPm5qo8+G26HEBrOHGcaC
kvYNWub22KIGMkMgvWHfifmGufY3DxYixrnjeiO5S5efUzyvrWt5w/pUuanF30O9Bb5H
An1CA+vT11npPvmmozAYrzoJa92mW+6wm1EdD3RwY1qjHGogvkiFSUuKgnDPNz8chkj1
Idbg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
s=arc-20240605;
h=to:subject:message-id:date:from:mime-version:dkim-signature;
bh=NhR8CX20yCvEyExzh29NWHPfXSGFfOcZFkoeKru54vk=;
fh=+R8aXOFVnuBbN1nRXJJI02Ia//JUQJmLW/Uk/VaA0ag=;
b=cG9SvSEpAXTjvdjxg+6rQIBxsWTPMUP1q42QubBjnb0xvc1qUqi3N0dF7/Vsxyvpci
MhzJtSQbUSlQX6P/egd41QwS95eXR83DiffIqJ6V+/VBePCuFgBdW27iPPNon7YLMPA5
fqXCj8F7B3V1fpmPzxk/y+Y0ba9RpPxN+AGmFS6iQ9Hi2XEnM3hbkE0cXhjDg3+MLad2
NFO4/IIv5z6SB4VFZdJm7bjZMJWy/CcSC7t95Zas2dwlWCOSIp8ACA0n2p2lBxO2/78m
Qt9sOWOhBuDPwpnE9keK/HRjrL5SHvIildfLJ/v34EkZ9cn/IMXvVgd9cNhI8Ngp35dI
As1A==; darn=gnu.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20251104; t=1779316330; x=1779921130; darn=gnu.org;
h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
:date:message-id:reply-to;
bh=NhR8CX20yCvEyExzh29NWHPfXSGFfOcZFkoeKru54vk=;
b=epkDSkAbL+qEpgNMvMxibjIk0rS+k9sQrJleYRAaEa83IYHIjgxV13OD3ZYMJPWGFk
BZPMA48TwGU9jB4hYXPeaCmUSSMq0lvmiOuB7nSNdJYavTAwHg4xGsI++afCeksPY/VC
V22+XlGYhTxGlEAKxkuCfKY5s7a672cz1rX+kbY8LksqrHNY1qzDaiimQ5iuHy+EyqFO
asPzIKXMdPl4vn7kcYRchlddJOVLHSr+12ijFntkgruWRRWECk86+I4eFCgX8GwaAocx
GzL4PkpLyYIhJe5VAsei2Ta3YicdP1ryZ+3guWpeKrSqlm2RH2NzNhbJOCXQHyB9tZEx
7Mfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20251104; t=1779316330; x=1779921130;
h=to:subject:message-id:date:from:mime-version:x-gm-gg
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=NhR8CX20yCvEyExzh29NWHPfXSGFfOcZFkoeKru54vk=;
b=YViV8bNjH2uEuarNlLtluAX2GwEoh3bwaR3m0sZLv6zJKfzSvSyq0ZOiuEqNV21DWa
1fOaAUp50wvcS1JI228nMGtuZxio5H9E+v+iBxYG29JoTsjUmyeb70ymCINKCzjE1By9
wT5EBxtQOSC0+fl194vTBbBUHeNNuHbAv7z50Z3Zq0h2OpyvsZT1apb3gPm3LFbsMguS
xWqL+fKeOrYiTxarUoDlK335PO3/zFHUHG6qbyWCu5v7Tylu+bqRfRiZF+juQBjg3OH+
7ovYgOUpinAJn4TB+yq8zB9fv5s1OH81mdSd+J97n0OmwSOiELXfMXVneXs6sgxfAEJ2
5lDg==
X-Gm-Message-State: AOJu0Yxz4edeoeDZtVGkn/7NQ59YsYCEndRyV9Fyp0xGS8Vus2SgSDI0
wPB06f8n1dXqb2b2SvPKzCGWW/ps0Ylu/CGbHcnmbvdnoPlSUXtJdp6JbQUhxDXJ4ydHdbV3AYb
eqgfja83zuXuZsYJpQVv8CmpDsvHY76D02QB5NoM=
X-Gm-Gg: Acq92OE7G81mljTjYxguqCFcdrPSqeCO2jzkhMckIA7j9tA1pplihwFdIbSO+CTWMCa
6ZnSrbrJE4Ksy0NjQXBTc3Kw/sgNixqh99LbXUxg2BLuXWJW+oQde4fCM12bOHXsqgR6gOClbDV
UszgLDYSzcH49Kl/DjUt0EEkxNEPTn736G2AKXnE+xyV8+A0GtjRSREQ+4c691F783cE1JqMCYA
zc9wKEC2AU/Rtb1fW28BEOmbrWfMzcIg6fUPY5ho4JWu0V1SJwf2nOYVB1J1AKSS1HwTpDhKU7m
6rZIohaocYm9yxyCPMWgqSGMliSE4Tgp4iSTHIzxKhIJ1RZ7Q3KuVQ2Mfs68eRM11XYMNtTN
X-Received: by 2002:a05:7022:384c:b0:135:dc82:85f7 with SMTP id
a92af1059eb24-13632a02a55mr271985c88.4.1779316329781; Wed, 20 May 2026
15:32:09 -0700 (PDT)
MIME-Version: 1.0
From: Eric Auld <eric.auld@HIDDEN>
Date: Wed, 20 May 2026 18:31:42 -0400
X-Gm-Features: AVHnY4JblAMnp9q0tA3zD_qd_P-NPBSV8P3qNe-DV54tMeYHpFQ_VaOYMc8l57k
Message-ID: <CAJoW6jc0FO20F5rigxFvVvAYHso=ihKHh34Tvx50SGmCiDx8cA@HIDDEN>
Subject: Emacs 30.2 on macOS retains ~500 MB RSS after closing most buffers
To: bug-gnu-emacs@HIDDEN
Content-Type: multipart/alternative; boundary="000000000000c79f3a0652475d35"
Received-SPF: pass client-ip=2607:f8b0:4864:20::122b;
envelope-from=eric.auld@HIDDEN; helo=mail-dl1-x122b.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 2.0 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Hello, I am seeing a high resident memory footprint from a
long-running GUI Emacs process on macOS. After closing many old buffers,
the same process is still using about 500 MB RSS with a modest number of bu
[...] Content analysis details: (2.0 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (eric.auld[at]gmail.com)
1.0 FORGED_GMAIL_RCVD 'From' gmail.com does not match 'Received'
headers -0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust [2001:470:142:0:0:0:0:17 listed in] [list.dnswl.org]
0.0 HTML_MESSAGE BODY: HTML included in message
X-Debbugs-Envelope-To: submit
X-Mailman-Approved-At: Thu, 21 May 2026 01:13:38 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)
--000000000000c79f3a0652475d35
Content-Type: text/plain; charset="UTF-8"
Hello,
I am seeing a high resident memory footprint from a long-running GUI Emacs
process on macOS. After closing many old buffers, the same process is still
using about 500 MB RSS with a modest number of buffers open.
Environment:
- GNU Emacs 30.2
- macOS
- App bundle: /Applications/Emacs.app
- Bundle identifier: org.gnu.Emacs
- Binary: /Applications/Emacs.app/Contents/MacOS/Emacs-arm64-11
Current process evidence:
- PID: 5400
- Started: Fri May 15 07:04:41 2026
- RSS from ps: 503,472 KB
- VSZ from ps: 421,853,376 KB
The process was queried with:
```sh
ps -p 5400 -o pid,lstart,rss,vsz,pmem,comm,args
```
After closing many old buffers, the live Emacs server reported:
```elisp
(:emacs-pid 5400
:buffer-count 33
:file-buffer-count 13
:markdown-buffer-count 12
:current-buffer " *server*"
:current-file nil)
```
That was collected with:
```sh
/Applications/Emacs.app/Contents/MacOS/bin/emacsclient --eval \
'(let* ((buffers (buffer-list))
(file-buffers
(seq-filter (lambda (b)
(buffer-local-value '\''buffer-file-name b))
buffers))
(md-buffers
(seq-filter (lambda (b)
(let ((f (buffer-local-value '\''buffer-file-name
b)))
(and f (string-match-p "\\.md\\'" f))))
buffers)))
(list :emacs-pid (emacs-pid)
:buffer-count (length buffers)
:file-buffer-count (length file-buffers)
:markdown-buffer-count (length md-buffers)
:current-buffer (buffer-name)
:current-file buffer-file-name))'
```
The concern is not that 500 MB RSS is necessarily impossible for Emacs, but
that the footprint remained high after reducing the number of open buffers
substantially. This makes it look not simply explained by having many
buffers
open.
I have not yet reproduced this under `emacs -Q`. If that is the next useful
step, I can try to gather the same process and buffer-count evidence from a
clean session.
Thanks.
--000000000000c79f3a0652475d35
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello,<br><br>I am seeing a high resident memory footprint=
from a long-running GUI Emacs<br>process on macOS. After closing many old =
buffers, the same process is still<br>using about 500 MB RSS with a modest =
number of buffers open.<br><br>Environment:<br><br>- GNU Emacs 30.2<br>- ma=
cOS<br>- App bundle: /Applications/Emacs.app<br>- Bundle identifier: org.gn=
u.Emacs<br>- Binary: /Applications/Emacs.app/Contents/MacOS/Emacs-arm64-11<=
br><br>Current process evidence:<br><br>- PID: 5400<br>- Started: Fri May 1=
5 07:04:41 2026<br>- RSS from ps: 503,472 KB<br>- VSZ from ps: 421,853,376 =
KB<br><br>The process was queried with:<br><br>```sh<br>ps -p 5400 -o pid,l=
start,rss,vsz,pmem,comm,args<br>```<br><br>After closing many old buffers, =
the live Emacs server reported:<br><br>```elisp<br>(:emacs-pid 5400<br>=C2=
=A0:buffer-count 33<br>=C2=A0:file-buffer-count 13<br>=C2=A0:markdown-buffe=
r-count 12<br>=C2=A0:current-buffer " *server*"<br>=C2=A0:current=
-file nil)<br>```<br><br>That was collected with:<br><br>```sh<br>/Applicat=
ions/Emacs.app/Contents/MacOS/bin/emacsclient --eval \<br>'(let* ((buff=
ers (buffer-list))<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (file-buffers<br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0(seq-filter (lambda (b)<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(buffer-local=
-value '\''buffer-file-name b))<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0buffers))<br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 (md-buffers<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(seq-filter =
(lambda (b)<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0(let ((f (buffer-local-value '\''buffer=
-file-name b)))<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(and f (string-match-p "\\.md\\'=
" f))))<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0buffers)))<br>=C2=A0 =C2=A0(list :emacs-pid (emacs-pid)<br=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:buffer-count (length buffers)<br>=C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0:file-buffer-count (length file-buffers)<br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:markdown-buffer-count (length md-buffers)<b=
r>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:current-buffer (buffer-name)<br>=C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0:current-file buffer-file-name))'<br>```<br=
><br>The concern is not that 500 MB RSS is necessarily impossible for Emacs=
, but<br>that the footprint remained high after reducing the number of open=
buffers<br>substantially. This makes it look not simply explained by havin=
g many buffers<br>open.<br><br>I have not yet reproduced this under `emacs =
-Q`. If that is the next useful<br>step, I can try to gather the same proce=
ss and buffer-count evidence from a<br>clean session.<br><br>Thanks.<br></d=
iv>
--000000000000c79f3a0652475d35--
Eric Auld <eric.auld@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#81087; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.