From unknown Sun Jul 20 11:23:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) Resent-From: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Jul 2025 07:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 79023 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 79023@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.175256361621873 (code B ref -1); Tue, 15 Jul 2025 07:14:01 +0000 Received: (at submit) by debbugs.gnu.org; 15 Jul 2025 07:13:36 +0000 Received: from localhost ([127.0.0.1]:39664 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ubZr2-0005gd-AH for submit@debbugs.gnu.org; Tue, 15 Jul 2025 03:13:35 -0400 Received: from lists.gnu.org ([2001:470:142::17]:39568) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ubZqv-0005fh-PB for submit@debbugs.gnu.org; Tue, 15 Jul 2025 03:13:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ubZqY-0001ND-QK for bug-gnu-emacs@gnu.org; Tue, 15 Jul 2025 03:13:06 -0400 Received: from fhigh-b5-smtp.messagingengine.com ([202.12.124.156]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ubZqR-0007j0-Ce for bug-gnu-emacs@gnu.org; Tue, 15 Jul 2025 03:13:02 -0400 Received: from phl-compute-04.internal (phl-compute-04.phl.internal [10.202.2.44]) by mailfhigh.stl.internal (Postfix) with ESMTP id 1960B7A0221 for ; Tue, 15 Jul 2025 03:12:51 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Tue, 15 Jul 2025 03:12:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaminski.se; h= cc:content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to; s=fm3; t=1752563570; x=1752649970; bh=nKk4V/xvvxIIMGxhDnzqiVyOnboH+wQr 93wFjeKdSCI=; b=YJ2LhM3pY7Y+pvNIe39T7KPT+o/FCfXjEGbXWByECRNdlD/i ME7U/KpIBC34t1tErlII1TE6KTUqae50ms8/OE1CkmoZAFLdpVTwcOylIUEhzxoN fQ8bmzwLAbt53A9R2BCyw8mlaTQu0Im8pUxBqzoTJKalnRhSo1MXIsOXvGPk5VSD tCfvjI2uEL+tZvOwkhu6V7v1BMDmkKHW4lkjcQ8EhOGaClBGL4IrMNXIh4uDtDn3 UhwYfaauHVNOZK/uyKCdCYdmsnug94q4RPa+5V3LotWbwfoV0eh/adfGnwuCfnM0 ytaeRfPcfNkDMqOvLIMFwniahp0lUXyIUhyKdg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1752563570; x= 1752649970; bh=nKk4V/xvvxIIMGxhDnzqiVyOnboH+wQr93wFjeKdSCI=; b=S FQRWeUKe9g3eIzqT5bRIw04ddsaYOVdBzngiTtwcwIfGn+3xUSKVSFra2pzDERHe bd8lJzI6guLnpnLBhXQfUMN6iXUGAE3Gu+U/g+KE7dUQTUdbQvKXUKS+4eiH4gkb rqJXc/kJypjKy6BHcymR4w0MIggxvOCtS7AqhmsEkpgwsBTQxQgseLDJDxZMBOtz m6a6DnjGik1ItYM+6hqXHklq/xqfBVjCGDzLfy96TT3n0a8TJ5kaF6Yf3K/F/gWO RMgo8Y8p/rR9G59ZW2IxuDgfAQ4+sYV4jmFERDeB7VoPq3cDs8L9dJ0dB0T0Ww+u lpKzCjAjm3H1zL1QS8PUw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdehgedulecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecunecujfgurhephffvufffoffkgggtsegrtdhmreertdejne cuhfhrohhmpefrrhiivghmhihslhgrficutehlvgigrghnuggvrhcumfgrmhhiknhskhhi uceophhriigvmhihshhlrgifsehkrghmihhnshhkihdrshgvqeenucggtffrrghtthgvrh hnpeevffdukeeugfeigfeuvedtuddvgefhieekuefhgeehieejudevieeiueeihedtuden ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehprhiivg hmhihslhgrfieskhgrmhhinhhskhhirdhsvgdpnhgspghrtghpthhtohepuddpmhhouggv pehsmhhtphhouhhtpdhrtghpthhtohepsghughdqghhnuhdqvghmrggtshesghhnuhdroh hrgh X-ME-Proxy: Feedback-ID: i08494404:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 15 Jul 2025 03:12:49 -0400 (EDT) From: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Date: Tue, 15 Jul 2025 09:12:47 +0200 X-Mailer: MailMate (1.14r5937) Message-ID: <5BA8A8B9-96CB-4823-836B-49CEBED77CEF@kaminski.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_5BFDFC84-962E-4F4C-BF89-4B08ECD1E283_=" Received-SPF: pass client-ip=202.12.124.156; envelope-from=przemyslaw@kaminski.se; helo=fhigh-b5-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) --=_MailMate_5BFDFC84-962E-4F4C-BF89-4B08ECD1E283_= Content-Type: text/plain; charset=UTF-8; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable Hi, it seems there's some memory leak happening in redisplay_internal function. I've noticed that over time Emacs become slower and slower. After 2-3 hours bug is noticable. Total - as reported by OS - usage is >2Gb. GC is working correctly and running it manually didn't change anything. Memory report marks only ~50mb, and total memory on relatively fresh instance is ~500mb. I've noticed that at approx 3Gb I start receiving "freezes of = doom". Previously I suspected vterm but I don't use vterm much if any. Can't say anything more, if there's anything else I could try to debug/report let me know. Best, Przemys=C5=82aw Alexander Kami=C5=84ski --- In GNU Emacs 30.1.90 (build 1, aarch64-apple-darwin24.5.0, NS appkit-2575.60 Version 15.5 (Build 24F74)) of 2025-06-20 built on = omega Windowing system distributor 'Apple', version 10.3.2575 System Description: macOS 15.5 Configured using: 'configure --disable-dependency-tracking --disable-silent-rules --enable-locallisppath=3D/opt/homebrew/share/emacs/site-lisp --infodir=3D/opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/info/= emacs --prefix=3D/opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5 --with-native-compilation=3Daot --with-xml2 --with-gnutls --without-compress-install --without-dbus --without-imagemagick --with-modules --with-rsvg --with-webp --with-ns --disable-ns-self-contained 'CFLAGS=3D-g -Og -O2 -DFD_SETSIZE=3D10000 -DDARWIN_UNLIMITED_SELECT -I/opt/homebrew/opt/sqlite/include -I/opt/homebrew/opt/gcc/include -I/opt/homebrew/opt/libgccjit/include' 'LDFLAGS=3D-L/opt/homebrew/opt/sqlite/lib -L/opt/homebrew/lib/gcc/15 -I/opt/homebrew/opt/gcc/include = -I/opt/homebrew/opt/libgccjit/include'' Configured features: ACL GIF GLIB GMP GNUTLS JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY KQUEUE NS PDUMPER PNG RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM ZLIB Important settings: value of $LC_ALL: en_US.UTF-8 value of $LC_CTYPE: pl_PL.UTF-8 value of $LANG: en_US.UTF-8 locale-coding-system: utf-8 Major mode: Lisp Interaction Minor modes in effect: global-git-commit-mode: t magit-auto-revert-mode: t aggressive-indent-mode: t paren-face-mode: t paredit-mode: t display-line-numbers-mode: t delete-selection-mode: t repeat-mode: t recentf-mode: t global-org-modern-mode: t async-bytecomp-package-mode: t winner-mode: t server-mode: t corfu-history-mode: t corfu-popupinfo-mode: t global-corfu-mode: t corfu-mode: t which-key-mode: t minions-mode: t vertico-mode: t display-time-mode: t adaptive-wrap-prefix-mode: t savehist-mode: t general-override-mode: t override-global-mode: t tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t undelete-frame-mode: t minibuffer-regexp-mode: t line-number-mode: t visual-line-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t abbrev-mode: t Load-path shadows: /Users/xlii/.emacs.d/elpa/emacsql-sqlite-builtin-20240825.1837/emacsql-sq= lite-builtin = hides = /Users/xlii/.emacs.d/elpa/emacsql-20250601.1009/emacsql-sqlite-builtin /Users/xlii/.emacs.d/elpa/which-key-20240620.2145/which-key hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= which-key /Users/xlii/.emacs.d/elpa/transient-20250701.1223/transient hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= transient /Users/xlii/.emacs.d/elpa/modus-themes-20250710.1713/theme-loaddefs = hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= theme-loaddefs /Users/xlii/.emacs.d/elpa/elixir-ts-mode-20241228.919/elixir-ts-mode = hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= progmodes/elixir-ts-mode /Users/xlii/.emacs.d/elpa/heex-ts-mode-20250511.643/heex-ts-mode hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= progmodes/heex-ts-mode /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-comint hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-comint /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-exp hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-exp /Users/xlii/.emacs.d/elpa/org-9.7.31/org-ctags hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-ctags /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-emacs-lisp hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-emacs-lisp /Users/xlii/.emacs.d/elpa/org-9.7.31/oc hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/oc /Users/xlii/.emacs.d/elpa/org-9.7.31/ox-texinfo hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ox-texinfo /Users/xlii/.emacs.d/elpa/org-9.7.31/ol-irc hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ol-irc /Users/xlii/.emacs.d/elpa/org-9.7.31/ol-doi hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ol-doi /Users/xlii/.emacs.d/elpa/org-9.7.31/ob hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob /Users/xlii/.emacs.d/elpa/org-9.7.31/org-refile hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-refile /Users/xlii/.emacs.d/elpa/org-9.7.31/org-version hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-version /Users/xlii/.emacs.d/elpa/org-9.7.31/org-num hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-num /Users/xlii/.emacs.d/elpa/org-9.7.31/ol-mhe hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ol-mhe /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-shell hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-shell /Users/xlii/.emacs.d/elpa/org-9.7.31/org-attach hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-attach /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-C hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-C /Users/xlii/.emacs.d/elpa/org-9.7.31/org-macs hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-macs /Users/xlii/.emacs.d/elpa/org-9.7.31/org-entities hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-entities /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-dot hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-dot /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-sql hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-sql /Users/xlii/.emacs.d/elpa/org-9.7.31/ol-eww hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ol-eww /Users/xlii/.emacs.d/elpa/org-9.7.31/org-datetree hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-datetree /Users/xlii/.emacs.d/elpa/org-9.7.31/org-macro hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-macro /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-eval hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-eval /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-haskell hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-haskell /Users/xlii/.emacs.d/elpa/org-9.7.31/ox-org hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ox-org /Users/xlii/.emacs.d/elpa/org-9.7.31/ol-rmail hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ol-rmail /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-awk hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-awk /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-groovy hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-groovy /Users/xlii/.emacs.d/elpa/org-9.7.31/ox-icalendar hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ox-icalendar /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-octave hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-octave /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-scheme hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-scheme /Users/xlii/.emacs.d/elpa/org-9.7.31/org-mobile hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-mobile /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-processing hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-processing /Users/xlii/.emacs.d/elpa/org-9.7.31/oc-biblatex hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/oc-biblatex /Users/xlii/.emacs.d/elpa/org-9.7.31/oc-csl hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/oc-csl /Users/xlii/.emacs.d/elpa/org-9.7.31/org-colview hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-colview /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-R hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-R /Users/xlii/.emacs.d/elpa/org-9.7.31/org-table hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-table /Users/xlii/.emacs.d/elpa/org-9.7.31/ox-html hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ox-html /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-fortran hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-fortran /Users/xlii/.emacs.d/elpa/org-9.7.31/ol hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ol /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-plantuml hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-plantuml /Users/xlii/.emacs.d/elpa/org-9.7.31/ol-docview hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ol-docview /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-perl hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-perl /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-sqlite hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-sqlite /Users/xlii/.emacs.d/elpa/org-9.7.31/oc-basic hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/oc-basic /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-sed hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-sed /Users/xlii/.emacs.d/elpa/org-9.7.31/org-fold-core hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-fold-core /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-ditaa hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-ditaa /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-ruby hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-ruby /Users/xlii/.emacs.d/elpa/org-9.7.31/oc-bibtex hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/oc-bibtex /Users/xlii/.emacs.d/elpa/org-9.7.31/org-habit hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-habit /Users/xlii/.emacs.d/elpa/org-9.7.31/org-loaddefs hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-loaddefs /Users/xlii/.emacs.d/elpa/org-9.7.31/ol-gnus hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ol-gnus /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-screen hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-screen /Users/xlii/.emacs.d/elpa/org-9.7.31/org-mouse hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-mouse /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-css hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-css /Users/xlii/.emacs.d/elpa/org-9.7.31/org-inlinetask hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-inlinetask /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-lisp hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-lisp /Users/xlii/.emacs.d/elpa/org-9.7.31/ol-eshell hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ol-eshell /Users/xlii/.emacs.d/elpa/org-9.7.31/org-pcomplete hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-pcomplete /Users/xlii/.emacs.d/elpa/org-9.7.31/org-lint hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-lint /Users/xlii/.emacs.d/elpa/org-9.7.31/org-id hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-id /Users/xlii/.emacs.d/elpa/org-9.7.31/org-capture hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-capture /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-sass hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-sass /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-tangle hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-tangle /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-calc hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-calc /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-java hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-java /Users/xlii/.emacs.d/elpa/org-9.7.31/org-compat hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-compat /Users/xlii/.emacs.d/elpa/org-9.7.31/org-attach-git hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-attach-git /Users/xlii/.emacs.d/elpa/org-9.7.31/ox-beamer hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ox-beamer /Users/xlii/.emacs.d/elpa/org-9.7.31/org-protocol hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-protocol /Users/xlii/.emacs.d/elpa/org-9.7.31/org-element hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-element /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-lob hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-lob /Users/xlii/.emacs.d/elpa/org-9.7.31/org-tempo hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-tempo /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-python hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-python /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-latex hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-latex /Users/xlii/.emacs.d/elpa/org-9.7.31/ol-w3m hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ol-w3m /Users/xlii/.emacs.d/elpa/org-9.7.31/org-agenda hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-agenda /Users/xlii/.emacs.d/elpa/org-9.7.31/org-persist hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-persist /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-ocaml hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-ocaml /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-ref hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-ref /Users/xlii/.emacs.d/elpa/org-9.7.31/org-fold hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-fold /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-julia hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-julia /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-lilypond hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-lilypond /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-table hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-table /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-clojure hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-clojure /Users/xlii/.emacs.d/elpa/org-9.7.31/org-indent hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-indent /Users/xlii/.emacs.d/elpa/org-9.7.31/org-plot hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-plot /Users/xlii/.emacs.d/elpa/org-9.7.31/ox-latex hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ox-latex /Users/xlii/.emacs.d/elpa/org-9.7.31/org-src hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-src /Users/xlii/.emacs.d/elpa/org-9.7.31/org-duration hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-duration /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-makefile hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-makefile /Users/xlii/.emacs.d/elpa/org-9.7.31/ol-info hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ol-info /Users/xlii/.emacs.d/elpa/org-9.7.31/org-clock hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-clock /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-forth hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-forth /Users/xlii/.emacs.d/elpa/org-9.7.31/ox-odt hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ox-odt /Users/xlii/.emacs.d/elpa/org-9.7.31/ol-man hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ol-man /Users/xlii/.emacs.d/elpa/org-9.7.31/ox-publish hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ox-publish /Users/xlii/.emacs.d/elpa/org-9.7.31/org-archive hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-archive /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-org hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-org /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-lua hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-lua /Users/xlii/.emacs.d/elpa/org-9.7.31/org-keys hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-keys /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-eshell hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-eshell /Users/xlii/.emacs.d/elpa/org-9.7.31/org-faces hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-faces /Users/xlii/.emacs.d/elpa/org-9.7.31/ox-man hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ox-man /Users/xlii/.emacs.d/elpa/org-9.7.31/org-list hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-list /Users/xlii/.emacs.d/elpa/org-9.7.31/ox-md hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ox-md /Users/xlii/.emacs.d/elpa/org-9.7.31/org-goto hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-goto /Users/xlii/.emacs.d/elpa/org-9.7.31/ol-bbdb hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ol-bbdb /Users/xlii/.emacs.d/elpa/org-9.7.31/org hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org /Users/xlii/.emacs.d/elpa/org-9.7.31/ol-bibtex hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ol-bibtex /Users/xlii/.emacs.d/elpa/org-9.7.31/ox-koma-letter hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ox-koma-letter /Users/xlii/.emacs.d/elpa/org-9.7.31/ox-ascii hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ox-ascii /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-matlab hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-matlab /Users/xlii/.emacs.d/elpa/org-9.7.31/ox hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ox /Users/xlii/.emacs.d/elpa/org-9.7.31/org-timer hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-timer /Users/xlii/.emacs.d/elpa/org-9.7.31/oc-natbib hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/oc-natbib /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-core hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-core /Users/xlii/.emacs.d/elpa/org-9.7.31/org-feed hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-feed /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-gnuplot hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-gnuplot /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-js hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-js /Users/xlii/.emacs.d/elpa/org-9.7.31/org-element-ast hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-element-ast /Users/xlii/.emacs.d/elpa/org-9.7.31/org-footnote hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-footnote /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-maxima hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/ob-maxima /Users/xlii/.emacs.d/elpa/org-9.7.31/org-cycle hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-cycle /Users/xlii/.emacs.d/elpa/org-9.7.31/org-crypt hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= org/org-crypt /Users/xlii/.emacs.d/elpa/eldoc-1.16.0/eldoc hides = /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/= emacs-lisp/eldoc Features: (shadow sort mail-extr autothemer git-msg-prefix git-ps1-mode magit-bookmark magit-submodule magit-blame magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit magit-sequence magit-notes magit-worktree magit-tag magit-merge magit-branch magit-reset magit-files magit-refs magit-status magit magit-repos magit-apply magit-wip magit-log which-func magit-diff smerge-mode diff git-commit log-edit pcvs-util add-log magit-core magit-autorevert autorevert magit-margin magit-transient magit-process with-editor magit-mode transient benchmark magit-git magit-base magit-section crm plantuml-mode deflate string-inflection emacsbug message yank-media rfc822 mml mml-sec epa gnus-util mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader sendmail mail-utils vertico-sort cursor-sensor vc-git diff-mode track-changes vc-dispatcher go-mode find-file etags fileloop expand-region text-mode-expansions cc-mode-expansions the-org-mode-expansions python-el-fgallina-expansions js-mode-expansions er-basic-expansions expand-region-core expand-region-custom aggressive-indent lisp-mnt paren-face paredit display-line-numbers delsel cus-load em-hist esh-mode esh-var ghub-legacy ghub-graphql treepy gsexp ghub url-http mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr url-gw url-auth llama gnutls dashboard dashboard-widgets rect ffap all-the-icons all-the-icons-faces data-material data-weathericons data-octicons data-fileicons data-faicons data-alltheicons repeat affe js c-ts-common cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs flycheck-clj-kondo flycheck jka-compr let-alist consult-lsp lsp lsp-mode lsp-protocol xref spinner network-stream nsm markdown-mode edit-indirect imenu ht filenotify ewoc epg rfc6068 epg-config recentf tree-widget consult bookmark pp ob-latex ob-clojure ob-prolog prolog align ob-sql ob-restclient restclient ob-python python project ob-dot ob-ruby ob-plantuml ob-shell org-tempo tempo org-crypt ob-js ox-md ox-odt rng-loc rng-uri rng-parse rng-match rng-dt rng-util rng-pttrn nxml-parse nxml-ns nxml-enc xmltok nxml-util ox-latex ox-icalendar org-agenda ox-html table ox-ascii ox-publish ox org-attach org-element org-persist xdg org-id org-refile org-element-ast inline avl-tree org-protocol f org-modern async-bytecomp async winner ayu-grey-theme ls-lisp server corfu-history corfu-popupinfo corfu which-key minions free-keys axk:toggle-truncate vertico-reverse vertico-repeat vertico-quick vertico cape-keyword dash eat term disp-table ehelp shell ediff ediff-merg ediff-mult ediff-wind ediff-diff ediff-help ediff-init ediff-util dired dired-loaddefs delight time shrface compile org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-src sh-script smie treesit executable ob-comint org-pcomplete org-list org-footnote org-faces org-entities time-date ob-emacs-lisp ob-core ob-eval org-cycle org-table ol org-fold org-fold-core org-keys oc org-loaddefs thingatpt find-func cal-menu calendar cal-loaddefs org-version org-compat org-macs shr text-property-search pixel-fill kinsoku url-file puny svg xml dom sqlformat reformatter hideshow noutline outline adaptive-wrap cape comp comp-cstr comp-run comp-common dabbrev orderless compat savehist visual-regexp avy-zap avy swiper ivy ivy-faces colir edmacro kmacro warnings memoize hydra lv s polymode derived poly-lock polymode-base polymode-weave polymode-export polymode-compat advice polymode-methods polymode-core format-spec polymode-classes eieio-custom wid-edit eieio-base color general cl-extra help-mode cl-libify cl exec-path-from-shell eshell esh-cmd generator esh-ext esh-opt esh-proc esh-io esh-arg pcomplete comint ansi-osc ansi-color ring esh-module esh-module-loaddefs esh-util files-x use-package use-package-ensure use-package-delight use-package-diminish use-package-bind-key bind-key use-package-core rx ace-window-autoloads ack-autoloads adaptive-wrap-autoloads affe-autoloads aggressive-indent-autoloads all-the-icons-autoloads atomic-chrome-autoloads avy-zap-autoloads awk-ts-mode-autoloads ayu-theme-autoloads base16-theme-autoloads browse-at-remote-autoloads cape-autoloads capf-autosuggest-autoloads cfrs-autoloads chatgpt-shell-autoloads citre-autoloads cl-libify-autoloads clips-mode-autoloads clj-refactor-autoloads cider-autoloads clojure-mode-autoloads color-theme-sanityinc-tomorrow-autoloads company-quickhelp-autoloads company-autoloads consult-dash-autoloads consult-flycheck-autoloads consult-lsp-autoloads consult-projectile-autoloads consult-yasnippet-autoloads copy-as-format-autoloads corfu-candidate-overlay-autoloads corfu-prescient-autoloads corfu-autoloads coterm-autoloads counsel-autoloads csv-mode-autoloads cue-mode-autoloads cyberpunk-theme-autoloads d2-mode-autoloads dash-docs-autoloads dashboard-autoloads datetime-autoloads dedicated-autoloads delight-autoloads devil-autoloads difftastic-autoloads dired-filter-autoloads dired-sidebar-autoloads dired-subtree-autoloads dired-hacks-utils-autoloads dirvish-autoloads doc-toc-autoloads dockerfile-mode-autoloads dracula-theme-autoloads earthfile-mode-autoloads eat-autoloads ediprolog-autoloads eglot-booster-autoloads eglot-x-autoloads el-mock-autoloads eldoc-box-autoloads elixir-ts-mode-autoloads emacsql-sqlite-builtin-autoloads embark-consult-autoloads consult-autoloads embark-autoloads eshell-vterm-autoloads esup-autoloads eterm-256color-autoloads exec-path-from-shell-autoloads expand-region-autoloads extmap-autoloads flycheck-clj-kondo-autoloads flycheck-credo-autoloads flymake-credo-autoloads flymake-flycheck-autoloads flycheck-autoloads free-keys-autoloads fzf-autoloads general-autoloads ghub-autoloads git-link-autoloads git-msg-prefix-autoloads git-ps1-mode-autoloads github-browse-file-autoloads go-mode-autoloads graphql-mode-autoloads graphviz-dot-mode-autoloads gruvbox-theme-autoloads autothemer-autoloads heex-ts-mode-autoloads highlight-autoloads highlight-indent-guides-autoloads highlight-indentation-autoloads hl-column-autoloads hyperbole-autoloads kotl-autoloads hact set hhist ialign-autoloads iedit-autoloads imenu-list-autoloads impatient-mode-autoloads inf-elixir-autoloads inflections-autoloads ivy-avy-autoloads avy-autoloads ivy-file-preview-autoloads ivy-posframe-autoloads janet-mode-autoloads jsonnet-mode-autoloads just-mode-autoloads kanagawa-theme-autoloads loccur-autoloads lsp-ui-autoloads lsp-mode-autoloads eldoc-autoloads lua-mode-autoloads magit-delta-autoloads marginalia-autoloads memoize-autoloads minions-autoloads mise-autoloads inheritenv-autoloads modus-themes-autoloads multiple-cursors-autoloads nano-theme-autoloads nord-theme-autoloads nordic-night-theme-autoloads ob-async-autoloads ob-prolog-autoloads ob-restclient-autoloads obsidian-autoloads elgrep-autoloads markdown-mode-autoloads orderless-autoloads org-appear-autoloads org-cliplink-autoloads org-clock-reminder-autoloads org-modern-autoloads org-ql-autoloads org-re-reveal-autoloads org-roam-ui-autoloads org-roam-autoloads emacsql-autoloads org-super-agenda-autoloads org-tidy-autoloads org-transclusion-autoloads outline-indent-autoloads ov-autoloads ox-clip-autoloads ox-gfm-autoloads ox-report-autoloads org-msg-autoloads htmlize-autoloads pabbrev-autoloads paredit-autoloads paren-face-autoloads parseedn-autoloads parseclj-autoloads pdf-tools-autoloads pfuture-autoloads pikchr-mode-autoloads pkl-mode-autoloads plantuml-mode-autoloads deflate-autoloads platformio-mode-autoloads async-autoloads polymode-autoloads popper-autoloads pos-tip-autoloads posframe-autoloads prescient-autoloads projectile-autoloads pueue-autoloads puni-autoloads easy-mmode quelpa-use-package-autoloads quelpa-autoloads queue-autoloads quick-peek-autoloads rainbow-delimiters-autoloads rainbow-mode-autoloads restclient-autoloads rich-minority-autoloads rust-mode-autoloads scss-mode-autoloads sed-mode-autoloads separedit-autoloads edit-indirect-autoloads sesman-autoloads shades-of-purple-theme-autoloads shell-maker-autoloads shrface-autoloads language-detection-autoloads org-autoloads shrink-path-autoloads f-autoloads sideline-blame-autoloads sideline-flymake-autoloads sideline-autoloads ht-autoloads simple-httpd-autoloads smartparens-autoloads solo-jazz-theme-autoloads souffle-mode-autoloads spacious-padding-autoloads spinner-autoloads sqlformat-autoloads string-inflection-autoloads swiper-autoloads ivy-autoloads tablist-autoloads tempel-autoloads textile-mode-autoloads theme-anchor-autoloads tla-ts-mode-autoloads treepy-autoloads treesit-auto-autoloads ts-autoloads s-autoloads dash-autoloads typst-ts-mode-autoloads ultra-scroll-autoloads finder-inf vc-jj-autoloads vc-msg-autoloads popup-autoloads vdiff-magit-autoloads magit-autoloads pcase transient-autoloads magit-section-autoloads llama-autoloads vdiff-autoloads hydra-autoloads lv-autoloads verb-autoloads vertico-autoloads visual-fill-column-autoloads visual-regexp-autoloads vterm-toggle-autoloads vterm-autoloads w3m-autoloads web-mode-autoloads websocket-autoloads wgrep-ack-autoloads wgrep-autoloads which-key-autoloads info with-editor-autoloads xr-autoloads xterm-color-autoloads yaml-mode-autoloads yaml-pro-autoloads yaml-autoloads yasnippet-capf-autoloads yasnippet-autoloads zig-mode-autoloads reformatter-autoloads zig-ts-mode-autoloads zmq-autoloads zones-autoloads zoutline-autoloads package browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs icons password-cache json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/ns-win ns-win ucs-normalize mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads kqueue cocoa ns lcms2 multi-tty make-network-process native-compile emacs) Memory information: ((conses 16 1101389 955140) (symbols 48 63300 46) (strings 32 266045 75482) (string-bytes 1 8549146) (vectors 16 85385) (vector-slots 8 994988 103443) (floats 8 1028 413) (intervals 56 1820 379) (buffers 992 14)) --=_MailMate_5BFDFC84-962E-4F4C-BF89-4B08ECD1E283_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

it seems there's some memory leak happening in redisplay_= internal
function.

I've noticed that over time Emacs become slower and slowe= r. After 2-3
hours bug is noticable. Total - as reported by OS - usage is >2Gb. GC = is
working correctly and running it manually didn't change anything. Memory<= br> report marks only ~50mb, and total memory on relatively fresh instance is ~500mb. I've noticed that at approx 3Gb I start receiving "freeze= s of doom".

Previously I suspected vterm but I don't use vterm much i= f any.

Can't say anything more, if there's anything else I could= try to
debug/report let me know.

Best,
Przemys=C5=82aw Alexander Kami=C5=84ski


In GNU Emacs 30.1.90 (build 1, aarch64-apple-darwin24.5.0= , NS
appkit-2575.60 Version 15.5 (Build 24F74)) of 2025-06-20 built on omega Windowing system distributor 'Apple', version 10.3.2575
System Description: macOS 15.5

Configured using:
'configure --disable-dependency-tracking --disable-silent-rules
--enable-locallisppath=3D/opt/homebrew/share/emacs/site-lisp
--infodir=3D/opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/info/em= acs
--prefix=3D/opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5
--with-native-compilation=3Daot --with-xml2 --with-gnutls
--without-compress-install --without-dbus --without-imagemagick
--with-modules --with-rsvg --with-webp --with-ns
--disable-ns-self-contained 'CFLAGS=3D-g -Og -O2 -DFD_SETSIZE=3D10000
= -DDARWIN_UNLIMITED_SELECT -I/opt/homebrew/opt/sqlite/include
-I/opt/homebrew/opt/gcc/include -I/opt/homebrew/opt/libgccjit/include' 'LDFLAGS=3D-L/opt/homebrew/opt/sqlite/lib -L/opt/homebrew/lib/gcc/15
-I/opt/homebrew/opt/gcc/include -I/opt/homebrew/opt/libgccjit/include''

Configured features:
ACL GIF GLIB GMP GNUTLS JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY
= KQUEUE NS PDUMPER PNG RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP XIM ZLIB

Important settings:
value of $LC_ALL: en_US.UTF-8
value of $LC_CTYPE: pl_PL.UTF-8
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8

Major mode: Lisp Interaction

Minor modes in effect:
global-git-commit-mode: t
magit-auto-revert-mode: t
aggressive-indent-mode: t
paren-face-mode: t
paredit-mode: t
display-line-numbers-mode: t
delete-selection-mode: t
repeat-mode: t
recentf-mode: t
global-org-modern-mode: t
async-bytecomp-package-mode: t
winner-mode: t
server-mode: t
corfu-history-mode: t
corfu-popupinfo-mode: t
global-corfu-mode: t
corfu-mode: t
which-key-mode: t
minions-mode: t
vertico-mode: t
display-time-mode: t
adaptive-wrap-prefix-mode: t
savehist-mode: t
general-override-mode: t
override-global-mode: t
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
undelete-frame-mode: t
minibuffer-regexp-mode: t
line-number-mode: t
visual-line-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
abbrev-mode: t

Load-path shadows:
/Users/xlii/.emacs.d/elpa/emacsql-sqlite-builtin-20240825.1837/emacsql-sq= lite-builtin hides /Users/xlii/.emacs.d/elpa/emacsql-20250601.1009/emacsq= l-sqlite-builtin
/Users/xlii/.emacs.d/elpa/which-key-20240620.2145/which-key hides /opt/ho= mebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/which-k= ey
/Users/xlii/.emacs.d/elpa/transient-20250701.1223/transient hides /opt/ho= mebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/transie= nt
/Users/xlii/.emacs.d/elpa/modus-themes-20250710.1713/theme-loaddefs hides= /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp= /theme-loaddefs
/Users/xlii/.emacs.d/elpa/elixir-ts-mode-20241228.919/elixir-ts-mode hide= s /opt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lis= p/progmodes/elixir-ts-mode
/Users/xlii/.emacs.d/elpa/heex-ts-mode-20250511.643/heex-ts-mode hides /o= pt/homebrew/Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/pr= ogmodes/heex-ts-mode
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-comint hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-comint
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-exp hides /opt/homebrew/Cellar/em= acs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-exp
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-ctags hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-ctags
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-emacs-lisp hides /opt/homebrew/Ce= llar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-emacs-lis= p
/Users/xlii/.emacs.d/elpa/org-9.7.31/oc hides /opt/homebrew/Cellar/emacs-= plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/oc
/Users/xlii/.emacs.d/elpa/org-9.7.31/ox-texinfo hides /opt/homebrew/Cella= r/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ox-texinfo
/Users/xlii/.emacs.d/elpa/org-9.7.31/ol-irc hides /opt/homebrew/Cellar/em= acs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ol-irc
/Users/xlii/.emacs.d/elpa/org-9.7.31/ol-doi hides /opt/homebrew/Cellar/em= acs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ol-doi
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob hides /opt/homebrew/Cellar/emacs-= plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-refile hides /opt/homebrew/Cella= r/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-refile
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-version hides /opt/homebrew/Cell= ar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-version /Users/xlii/.emacs.d/elpa/org-9.7.31/org-num hides /opt/homebrew/Cellar/e= macs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-num
/Users/xlii/.emacs.d/elpa/org-9.7.31/ol-mhe hides /opt/homebrew/Cellar/em= acs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ol-mhe
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-shell hides /opt/homebrew/Cellar/= emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-shell
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-attach hides /opt/homebrew/Cella= r/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-attach
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-C hides /opt/homebrew/Cellar/emac= s-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-C
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-macs hides /opt/homebrew/Cellar/= emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-macs
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-entities hides /opt/homebrew/Cel= lar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-entities<= br> /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-dot hides /opt/homebrew/Cellar/em= acs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-dot
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-sql hides /opt/homebrew/Cellar/em= acs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-sql
/Users/xlii/.emacs.d/elpa/org-9.7.31/ol-eww hides /opt/homebrew/Cellar/em= acs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ol-eww
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-datetree hides /opt/homebrew/Cel= lar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-datetree<= br> /Users/xlii/.emacs.d/elpa/org-9.7.31/org-macro hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-macro
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-eval hides /opt/homebrew/Cellar/e= macs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-eval
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-haskell hides /opt/homebrew/Cella= r/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-haskell
/Users/xlii/.emacs.d/elpa/org-9.7.31/ox-org hides /opt/homebrew/Cellar/em= acs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ox-org
/Users/xlii/.emacs.d/elpa/org-9.7.31/ol-rmail hides /opt/homebrew/Cellar/= emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ol-rmail
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-awk hides /opt/homebrew/Cellar/em= acs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-awk
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-groovy hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-groovy
/Users/xlii/.emacs.d/elpa/org-9.7.31/ox-icalendar hides /opt/homebrew/Cel= lar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ox-icalendar<= br> /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-octave hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-octave
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-scheme hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-scheme
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-mobile hides /opt/homebrew/Cella= r/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-mobile
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-processing hides /opt/homebrew/Ce= llar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-processin= g
/Users/xlii/.emacs.d/elpa/org-9.7.31/oc-biblatex hides /opt/homebrew/Cell= ar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/oc-biblatex /Users/xlii/.emacs.d/elpa/org-9.7.31/oc-csl hides /opt/homebrew/Cellar/em= acs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/oc-csl
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-colview hides /opt/homebrew/Cell= ar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-colview /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-R hides /opt/homebrew/Cellar/emac= s-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-R
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-table hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-table
/Users/xlii/.emacs.d/elpa/org-9.7.31/ox-html hides /opt/homebrew/Cellar/e= macs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ox-html
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-fortran hides /opt/homebrew/Cella= r/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-fortran
/Users/xlii/.emacs.d/elpa/org-9.7.31/ol hides /opt/homebrew/Cellar/emacs-= plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ol
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-plantuml hides /opt/homebrew/Cell= ar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-plantuml /Users/xlii/.emacs.d/elpa/org-9.7.31/ol-docview hides /opt/homebrew/Cella= r/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ol-docview
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-perl hides /opt/homebrew/Cellar/e= macs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-perl
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-sqlite hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-sqlite
/Users/xlii/.emacs.d/elpa/org-9.7.31/oc-basic hides /opt/homebrew/Cellar/= emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/oc-basic
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-sed hides /opt/homebrew/Cellar/em= acs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-sed
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-fold-core hides /opt/homebrew/Ce= llar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-fold-cor= e
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-ditaa hides /opt/homebrew/Cellar/= emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-ditaa
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-ruby hides /opt/homebrew/Cellar/e= macs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-ruby
/Users/xlii/.emacs.d/elpa/org-9.7.31/oc-bibtex hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/oc-bibtex
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-habit hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-habit
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-loaddefs hides /opt/homebrew/Cel= lar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-loaddefs<= br> /Users/xlii/.emacs.d/elpa/org-9.7.31/ol-gnus hides /opt/homebrew/Cellar/e= macs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ol-gnus
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-screen hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-screen
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-mouse hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-mouse
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-css hides /opt/homebrew/Cellar/em= acs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-css
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-inlinetask hides /opt/homebrew/C= ellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-inlinet= ask
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-lisp hides /opt/homebrew/Cellar/e= macs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-lisp
/Users/xlii/.emacs.d/elpa/org-9.7.31/ol-eshell hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ol-eshell
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-pcomplete hides /opt/homebrew/Ce= llar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-pcomplet= e
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-lint hides /opt/homebrew/Cellar/= emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-lint
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-id hides /opt/homebrew/Cellar/em= acs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-id
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-capture hides /opt/homebrew/Cell= ar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-capture /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-sass hides /opt/homebrew/Cellar/e= macs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-sass
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-tangle hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-tangle
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-calc hides /opt/homebrew/Cellar/e= macs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-calc
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-java hides /opt/homebrew/Cellar/e= macs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-java
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-compat hides /opt/homebrew/Cella= r/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-compat
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-attach-git hides /opt/homebrew/C= ellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-attach-= git
/Users/xlii/.emacs.d/elpa/org-9.7.31/ox-beamer hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ox-beamer
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-protocol hides /opt/homebrew/Cel= lar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-protocol<= br> /Users/xlii/.emacs.d/elpa/org-9.7.31/org-element hides /opt/homebrew/Cell= ar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-element /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-lob hides /opt/homebrew/Cellar/em= acs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-lob
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-tempo hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-tempo
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-python hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-python
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-latex hides /opt/homebrew/Cellar/= emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-latex
/Users/xlii/.emacs.d/elpa/org-9.7.31/ol-w3m hides /opt/homebrew/Cellar/em= acs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ol-w3m
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-agenda hides /opt/homebrew/Cella= r/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-agenda
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-persist hides /opt/homebrew/Cell= ar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-persist /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-ocaml hides /opt/homebrew/Cellar/= emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-ocaml
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-ref hides /opt/homebrew/Cellar/em= acs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-ref
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-fold hides /opt/homebrew/Cellar/= emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-fold
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-julia hides /opt/homebrew/Cellar/= emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-julia
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-lilypond hides /opt/homebrew/Cell= ar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-lilypond /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-table hides /opt/homebrew/Cellar/= emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-table
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-clojure hides /opt/homebrew/Cella= r/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-clojure
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-indent hides /opt/homebrew/Cella= r/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-indent
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-plot hides /opt/homebrew/Cellar/= emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-plot
/Users/xlii/.emacs.d/elpa/org-9.7.31/ox-latex hides /opt/homebrew/Cellar/= emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ox-latex
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-src hides /opt/homebrew/Cellar/e= macs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-src
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-duration hides /opt/homebrew/Cel= lar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-duration<= br> /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-makefile hides /opt/homebrew/Cell= ar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-makefile /Users/xlii/.emacs.d/elpa/org-9.7.31/ol-info hides /opt/homebrew/Cellar/e= macs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ol-info
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-clock hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-clock
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-forth hides /opt/homebrew/Cellar/= emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-forth
/Users/xlii/.emacs.d/elpa/org-9.7.31/ox-odt hides /opt/homebrew/Cellar/em= acs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ox-odt
/Users/xlii/.emacs.d/elpa/org-9.7.31/ol-man hides /opt/homebrew/Cellar/em= acs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ol-man
/Users/xlii/.emacs.d/elpa/org-9.7.31/ox-publish hides /opt/homebrew/Cella= r/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ox-publish
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-archive hides /opt/homebrew/Cell= ar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-archive /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-org hides /opt/homebrew/Cellar/em= acs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-org
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-lua hides /opt/homebrew/Cellar/em= acs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-lua
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-keys hides /opt/homebrew/Cellar/= emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-keys
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-eshell hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-eshell
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-faces hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-faces
/Users/xlii/.emacs.d/elpa/org-9.7.31/ox-man hides /opt/homebrew/Cellar/em= acs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ox-man
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-list hides /opt/homebrew/Cellar/= emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-list
/Users/xlii/.emacs.d/elpa/org-9.7.31/ox-md hides /opt/homebrew/Cellar/ema= cs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ox-md
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-goto hides /opt/homebrew/Cellar/= emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-goto
/Users/xlii/.emacs.d/elpa/org-9.7.31/ol-bbdb hides /opt/homebrew/Cellar/e= macs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ol-bbdb
/Users/xlii/.emacs.d/elpa/org-9.7.31/org hides /opt/homebrew/Cellar/emacs= -plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org
/Users/xlii/.emacs.d/elpa/org-9.7.31/ol-bibtex hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ol-bibtex
/Users/xlii/.emacs.d/elpa/org-9.7.31/ox-koma-letter hides /opt/homebrew/C= ellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ox-koma-let= ter
/Users/xlii/.emacs.d/elpa/org-9.7.31/ox-ascii hides /opt/homebrew/Cellar/= emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ox-ascii
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-matlab hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-matlab
/Users/xlii/.emacs.d/elpa/org-9.7.31/ox hides /opt/homebrew/Cellar/emacs-= plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ox
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-timer hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-timer
/Users/xlii/.emacs.d/elpa/org-9.7.31/oc-natbib hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/oc-natbib
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-core hides /opt/homebrew/Cellar/e= macs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-core
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-feed hides /opt/homebrew/Cellar/= emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-feed
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-gnuplot hides /opt/homebrew/Cella= r/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-gnuplot
/Users/xlii/.emacs.d/elpa/org-9.7.31/ob-js hides /opt/homebrew/Cellar/ema= cs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-js
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-element-ast hides /opt/homebrew/= Cellar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-elemen= t-ast
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-footnote hides /opt/homebrew/Cel= lar/emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-footnote<= br> /Users/xlii/.emacs.d/elpa/org-9.7.31/ob-maxima hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/ob-maxima
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-cycle hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-cycle
/Users/xlii/.emacs.d/elpa/org-9.7.31/org-crypt hides /opt/homebrew/Cellar= /emacs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/org/org-crypt
/Users/xlii/.emacs.d/elpa/eldoc-1.16.0/eldoc hides /opt/homebrew/Cellar/e= macs-plus@30/HEAD-a2bfce5/share/emacs/30.1.90/lisp/emacs-lisp/eldoc

Features:
(shadow sort mail-extr autothemer git-msg-prefix git-ps1-mode
magit-bookmark magit-submodule magit-blame magit-stash magit-reflog
magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit magit-sequence magit-notes magit-worktree magit-tag
magit-merge magit-branch magit-reset magit-files magit-refs magit-status<= br> magit magit-repos magit-apply magit-wip magit-log which-func magit-diff smerge-mode diff git-commit log-edit pcvs-util add-log magit-core
magit-autorevert autorevert magit-margin magit-transient magit-process with-editor magit-mode transient benchmark magit-git magit-base
magit-section crm plantuml-mode deflate string-inflection emacsbug
message yank-media rfc822 mml mml-sec epa gnus-util mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader sendmail mail-utils
vertico-sort cursor-sensor vc-git diff-mode track-changes vc-dispatcher go-mode find-file etags fileloop expand-region text-mode-expansions
cc-mode-expansions the-org-mode-expansions python-el-fgallina-expansions<= br> js-mode-expansions er-basic-expansions expand-region-core
expand-region-custom aggressive-indent lisp-mnt paren-face paredit
display-line-numbers delsel cus-load em-hist esh-mode esh-var
ghub-legacy ghub-graphql treepy gsexp ghub url-http mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr url-gw url-auth llama
gnutls dashboard dashboard-widgets rect ffap all-the-icons
all-the-icons-faces data-material data-weathericons data-octicons
data-fileicons data-faicons data-alltheicons repeat affe js c-ts-common cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs flycheck-clj-kondo flycheck jka-compr let-alist
consult-lsp lsp lsp-mode lsp-protocol xref spinner network-stream nsm
= markdown-mode edit-indirect imenu ht filenotify ewoc epg rfc6068
epg-config recentf tree-widget consult bookmark pp ob-latex ob-clojure ob-prolog prolog align ob-sql ob-restclient restclient ob-python python project ob-dot ob-ruby ob-plantuml ob-shell org-tempo tempo org-crypt
= ob-js ox-md ox-odt rng-loc rng-uri rng-parse rng-match rng-dt rng-util rng-pttrn nxml-parse nxml-ns nxml-enc xmltok nxml-util ox-latex
ox-icalendar org-agenda ox-html table ox-ascii ox-publish ox org-attach org-element org-persist xdg org-id org-refile org-element-ast inline
avl-tree org-protocol f org-modern async-bytecomp async winner
ayu-grey-theme ls-lisp server corfu-history corfu-popupinfo corfu
which-key minions free-keys axk:toggle-truncate vertico-reverse
vertico-repeat vertico-quick vertico cape-keyword dash eat term
disp-table ehelp shell ediff ediff-merg ediff-mult ediff-wind ediff-diff<= br> ediff-help ediff-init ediff-util dired dired-loaddefs delight time
shrface compile org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro<= br> org-src sh-script smie treesit executable ob-comint org-pcomplete
org-list org-footnote org-faces org-entities time-date ob-emacs-lisp
ob-core ob-eval org-cycle org-table ol org-fold org-fold-core org-keys oc org-loaddefs thingatpt find-func cal-menu calendar cal-loaddefs
org-version org-compat org-macs shr text-property-search pixel-fill
kinsoku url-file puny svg xml dom sqlformat reformatter hideshow
noutline outline adaptive-wrap cape comp comp-cstr comp-run comp-common dabbrev orderless compat savehist visual-regexp avy-zap avy swiper ivy ivy-faces colir edmacro kmacro warnings memoize hydra lv s polymode
derived poly-lock polymode-base polymode-weave polymode-export
polymode-compat advice polymode-methods polymode-core format-spec
polymode-classes eieio-custom wid-edit eieio-base color general cl-extra<= br> help-mode cl-libify cl exec-path-from-shell eshell esh-cmd generator
esh-ext esh-opt esh-proc esh-io esh-arg pcomplete comint ansi-osc
ansi-color ring esh-module esh-module-loaddefs esh-util files-x
use-package use-package-ensure use-package-delight use-package-diminish use-package-bind-key bind-key use-package-core rx ace-window-autoloads ack-autoloads adaptive-wrap-autoloads affe-autoloads
aggressive-indent-autoloads all-the-icons-autoloads
atomic-chrome-autoloads avy-zap-autoloads awk-ts-mode-autoloads
ayu-theme-autoloads base16-theme-autoloads browse-at-remote-autoloads
= cape-autoloads capf-autosuggest-autoloads cfrs-autoloads
chatgpt-shell-autoloads citre-autoloads cl-libify-autoloads
clips-mode-autoloads clj-refactor-autoloads cider-autoloads
clojure-mode-autoloads color-theme-sanityinc-tomorrow-autoloads
company-quickhelp-autoloads company-autoloads consult-dash-autoloads
consult-flycheck-autoloads consult-lsp-autoloads
consult-projectile-autoloads consult-yasnippet-autoloads
copy-as-format-autoloads corfu-candidate-overlay-autoloads
corfu-prescient-autoloads corfu-autoloads coterm-autoloads
counsel-autoloads csv-mode-autoloads cue-mode-autoloads
cyberpunk-theme-autoloads d2-mode-autoloads dash-docs-autoloads
dashboard-autoloads datetime-autoloads dedicated-autoloads
delight-autoloads devil-autoloads difftastic-autoloads
dired-filter-autoloads dired-sidebar-autoloads dired-subtree-autoloads dired-hacks-utils-autoloads dirvish-autoloads doc-toc-autoloads
dockerfile-mode-autoloads dracula-theme-autoloads
earthfile-mode-autoloads eat-autoloads ediprolog-autoloads
eglot-booster-autoloads eglot-x-autoloads el-mock-autoloads
eldoc-box-autoloads elixir-ts-mode-autoloads
emacsql-sqlite-builtin-autoloads embark-consult-autoloads
consult-autoloads embark-autoloads eshell-vterm-autoloads esup-autoloads<= br> eterm-256color-autoloads exec-path-from-shell-autoloads
expand-region-autoloads extmap-autoloads flycheck-clj-kondo-autoloads
= flycheck-credo-autoloads flymake-credo-autoloads
flymake-flycheck-autoloads flycheck-autoloads free-keys-autoloads
fzf-autoloads general-autoloads ghub-autoloads git-link-autoloads
git-msg-prefix-autoloads git-ps1-mode-autoloads
github-browse-file-autoloads go-mode-autoloads graphql-mode-autoloads
= graphviz-dot-mode-autoloads gruvbox-theme-autoloads autothemer-autoloads<= br> heex-ts-mode-autoloads highlight-autoloads
highlight-indent-guides-autoloads highlight-indentation-autoloads
hl-column-autoloads hyperbole-autoloads kotl-autoloads hact set hhist
= ialign-autoloads iedit-autoloads imenu-list-autoloads
impatient-mode-autoloads inf-elixir-autoloads inflections-autoloads
ivy-avy-autoloads avy-autoloads ivy-file-preview-autoloads
ivy-posframe-autoloads janet-mode-autoloads jsonnet-mode-autoloads
just-mode-autoloads kanagawa-theme-autoloads loccur-autoloads
lsp-ui-autoloads lsp-mode-autoloads eldoc-autoloads lua-mode-autoloads magit-delta-autoloads marginalia-autoloads memoize-autoloads
minions-autoloads mise-autoloads inheritenv-autoloads
modus-themes-autoloads multiple-cursors-autoloads nano-theme-autoloads nord-theme-autoloads nordic-night-theme-autoloads ob-async-autoloads
ob-prolog-autoloads ob-restclient-autoloads obsidian-autoloads
elgrep-autoloads markdown-mode-autoloads orderless-autoloads
org-appear-autoloads org-cliplink-autoloads org-clock-reminder-autoloads<= br> org-modern-autoloads org-ql-autoloads org-re-reveal-autoloads
org-roam-ui-autoloads org-roam-autoloads emacsql-autoloads
org-super-agenda-autoloads org-tidy-autoloads org-transclusion-autoloads<= br> outline-indent-autoloads ov-autoloads ox-clip-autoloads ox-gfm-autoloads<= br> ox-report-autoloads org-msg-autoloads htmlize-autoloads
pabbrev-autoloads paredit-autoloads paren-face-autoloads
parseedn-autoloads parseclj-autoloads pdf-tools-autoloads
pfuture-autoloads pikchr-mode-autoloads pkl-mode-autoloads
plantuml-mode-autoloads deflate-autoloads platformio-mode-autoloads
async-autoloads polymode-autoloads popper-autoloads pos-tip-autoloads
= posframe-autoloads prescient-autoloads projectile-autoloads
pueue-autoloads puni-autoloads easy-mmode quelpa-use-package-autoloads quelpa-autoloads queue-autoloads quick-peek-autoloads
rainbow-delimiters-autoloads rainbow-mode-autoloads restclient-autoloads<= br> rich-minority-autoloads rust-mode-autoloads scss-mode-autoloads
sed-mode-autoloads separedit-autoloads edit-indirect-autoloads
sesman-autoloads shades-of-purple-theme-autoloads shell-maker-autoloads shrface-autoloads language-detection-autoloads org-autoloads
shrink-path-autoloads f-autoloads sideline-blame-autoloads
sideline-flymake-autoloads sideline-autoloads ht-autoloads
simple-httpd-autoloads smartparens-autoloads solo-jazz-theme-autoloads souffle-mode-autoloads spacious-padding-autoloads spinner-autoloads
sqlformat-autoloads string-inflection-autoloads swiper-autoloads
ivy-autoloads tablist-autoloads tempel-autoloads textile-mode-autoloads theme-anchor-autoloads tla-ts-mode-autoloads treepy-autoloads
treesit-auto-autoloads ts-autoloads s-autoloads dash-autoloads
typst-ts-mode-autoloads ultra-scroll-autoloads finder-inf
vc-jj-autoloads vc-msg-autoloads popup-autoloads vdiff-magit-autoloads magit-autoloads pcase transient-autoloads magit-section-autoloads
llama-autoloads vdiff-autoloads hydra-autoloads lv-autoloads
verb-autoloads vertico-autoloads visual-fill-column-autoloads
visual-regexp-autoloads vterm-toggle-autoloads vterm-autoloads
w3m-autoloads web-mode-autoloads websocket-autoloads wgrep-ack-autoloads<= br> wgrep-autoloads which-key-autoloads info with-editor-autoloads
xr-autoloads xterm-color-autoloads yaml-mode-autoloads
yaml-pro-autoloads yaml-autoloads yasnippet-capf-autoloads
yasnippet-autoloads zig-mode-autoloads reformatter-autoloads
zig-ts-mode-autoloads zmq-autoloads zones-autoloads zoutline-autoloads package browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie generate-lisp-file url-domsuf url-util mailcap
= url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs icons<= br> password-cache json subr-x map byte-opt gv bytecomp byte-compile
url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/ns-win ns-win ucs-normalize mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow<= br> isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax<= br> font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic<= br> indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads kqueue cocoa ns lcms2
multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 1101389 955140) (symbols 48 63300 46)
(strings 32 266045 75482) (string-bytes 1 8549146) (vectors 16 85385)
= (vector-slots 8 994988 103443) (floats 8 1028 413)
(intervals 56 1820 379) (buffers 992 14))

--=_MailMate_5BFDFC84-962E-4F4C-BF89-4B08ECD1E283_=-- From unknown Sun Jul 20 11:23:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Jul 2025 12:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79023 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Cc: 79023@debbugs.gnu.org Received: via spool by 79023-submit@debbugs.gnu.org id=B79023.175258220710839 (code B ref 79023); Tue, 15 Jul 2025 12:24:02 +0000 Received: (at 79023) by debbugs.gnu.org; 15 Jul 2025 12:23:27 +0000 Received: from localhost ([127.0.0.1]:40840 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ubegw-0002ok-Us for submit@debbugs.gnu.org; Tue, 15 Jul 2025 08:23:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60506) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ubegs-0002oM-NX for 79023@debbugs.gnu.org; Tue, 15 Jul 2025 08:23:23 -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 ) id 1ubegl-0005hx-O2; Tue, 15 Jul 2025 08:23:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=/xt1+Vd24OHS9SHwcNnQGkEVEs3iIezlEoalj2V6nYw=; b=f7LXMFyrjISecI39TKSh 6ga+tOubuF4oH79UuaVIC7TWop5fejq8SUpoq3gNBftBB8FuqSv3Iy73JB90OZ+JcjzKzejZOk0/M gJSKFSl/0Dzbt+hhkL/ohWPmCrkgjTSFiB93LDh/DnhZMdf+SbpNKkK+mJV9vhOe9b/G2KWpawEq4 vWQt/iyJkEjssaKvpRmc9Loa89eVFl/QYahUOrr4Ne4usg1I+c9v8xDnutnGvR5W8oWEwsMmPDeWc d3pq7bHznYXPk4HYORZ0sFQpn+D9OdRLJEVljWbq/CKFo4Y4BjfifokeZC2f8bEVaqg+vvkEmub7I z+EZqQQboPLppA==; Date: Tue, 15 Jul 2025 15:23:13 +0300 Message-Id: <86ldopk5hq.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <5BA8A8B9-96CB-4823-836B-49CEBED77CEF@kaminski.se> (przemyslaw@kaminski.se) References: <5BA8A8B9-96CB-4823-836B-49CEBED77CEF@kaminski.se> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Przemysław Alexander Kamiński > > Date: Tue, 15 Jul 2025 09:12:47 +0200 > > it seems there's some memory leak happening in redisplay_internal > function. > > I've noticed that over time Emacs become slower and slower. After 2-3 > hours bug is noticable. Total - as reported by OS - usage is >2Gb. GC is > working correctly and running it manually didn't change anything. Memory > report marks only ~50mb, and total memory on relatively fresh instance > is ~500mb. I've noticed that at approx 3Gb I start receiving "freezes of doom". Given the above description, why did you decide the leak is in redisplay_internal? FWIW, I'm using Emacs 30.1.90 all the time, with sessions that last several weeks, and its memory footprint, after leveling at several hundred MB never grows more, certainly not at the rate you describe. So either this is a macOS-specific problem, or something else is at work here (perhaps one of the many packages you have activated?). > Can't say anything more, if there's anything else I could try to > debug/report let me know. Well, for starters please explain why you think it's redisplay_internal that leaks. Also, if you can try older versions of Emacs, please see if the same issue exists there. And finally, what version of Emacs are you using and how did you build it? Is that Emacs 30.1.90 pretest built from the pretest tarball, or is it something else? Thanks. From unknown Sun Jul 20 11:23:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) Resent-From: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Jul 2025 13:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79023 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 79023@debbugs.gnu.org Received: via spool by 79023-submit@debbugs.gnu.org id=B79023.175258453319617 (code B ref 79023); Tue, 15 Jul 2025 13:03:02 +0000 Received: (at 79023) by debbugs.gnu.org; 15 Jul 2025 13:02:13 +0000 Received: from localhost ([127.0.0.1]:40988 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ubfIR-00056J-Do for submit@debbugs.gnu.org; Tue, 15 Jul 2025 09:02:13 -0400 Received: from fhigh-a3-smtp.messagingengine.com ([103.168.172.154]:56457) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ubfIL-00055i-KG for 79023@debbugs.gnu.org; Tue, 15 Jul 2025 09:02:10 -0400 Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47]) by mailfhigh.phl.internal (Postfix) with ESMTP id 8FD4E14002E9; Tue, 15 Jul 2025 09:01:59 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-07.internal (MEProxy); Tue, 15 Jul 2025 09:01:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaminski.se; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1752584519; x=1752670919; bh=PrEnAOQo58iatHGWawySKb5em+Kt5JsUpHSfcxzzZyk=; b= oKSgJPD8Jgr7ff4O2FKeULBjXGjaOSmnhh90gR3hsID6j1wTTao1qXuFd8xmAc5/ iVoR/Au9dhOd4pQFY92YCKfclO92o05X3GfXIH0rBBplcO4vqFM7R05hkmayBoTC Pfcma63x37/Kd290UONQHb2FjTJx9+/6f22E0EjPOPaw1Il3OREtbS6MjOQKdzdl gPURj+4jRorfztigou+q+TyLn+zMOwn6Pt/GK7nMWSHW6b4t7ClmOp8KjpOJhgr1 2PSP0Y8ssg5dDfaqnmFY88X7ggv5s2W3rmIqAwKFKjV3PFc4EMG0x4AQtQkvT12C eGdfLt7Tpv8d9otjK446kQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1752584519; x= 1752670919; bh=PrEnAOQo58iatHGWawySKb5em+Kt5JsUpHSfcxzzZyk=; b=I F85oE+YWEKS0tr9RxXNhzO3X+z+KgfvYX8W/KE/VSEcuzKC4ItIz8VQxlGLqcrIn R5Bx3H72qHSetodagFOynYG5CpuP9JbssCWzIldUNZXVtK/cZ4MS5g/ygsremk4m 8H/KVnIijiIvBmjq6IL5+J4Z3tsQuQuYQbixDAu4IXBTSAes+HSeY1rP8TjADFA8 6zz0C6/J0H1PHOK/nxbp7zZGYB3Dv1baDMPokE/7qDNiASN24mg+zzx58Q8sUkEb yGDRaH2nfovd3jzlGNIPLdLaQDFjr8gmnUAOo4Q9MyTl5smjoTBwSuuHBEOQfO8A 6qKhiz+qHYBfSsq1uGUww== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdehgeeltdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffoffkjghfgggtgfesrgekmherredtjeenucfhrhhomheprfhriigvmhih shhlrgifucetlhgvgigrnhguvghrucfmrghmihnkshhkihcuoehprhiivghmhihslhgrfi eskhgrmhhinhhskhhirdhsvgeqnecuggftrfgrthhtvghrnheptddvteevheevheeihefg tdfhjedtvedtveduudfhgfejgeelvdfhvdfhffehheffnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepphhriigvmhihshhlrgifsehkrghmihhn shhkihdrshgvpdhnsggprhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprhgtph htthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopeejledtvdefseguvggssghu ghhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i08494404:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 15 Jul 2025 09:01:58 -0400 (EDT) From: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Date: Tue, 15 Jul 2025 15:01:55 +0200 X-Mailer: MailMate (1.14r5937) Message-ID: <113CE362-63BF-4F13-845C-1DB8F6D8580C@kaminski.se> In-Reply-To: <86ldopk5hq.fsf@gnu.org> References: <5BA8A8B9-96CB-4823-836B-49CEBED77CEF@kaminski.se> <86ldopk5hq.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_00503FBC-C382-443C-87A9-1053E89B82BF_=" Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=_MailMate_00503FBC-C382-443C-87A9-1053E89B82BF_= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 15 Jul 2025, at 14:23, Eli Zaretskii wrote: > Given the above description, why did you decide the leak is in > redisplay_internal? 39,652,925 72% - redisplay_internal (C function) 1,797,080 3% + eval 279,056 0% + jit-lock-function 66,632 0% + which-key--hide-popup-on-frame-size-change 24,752 0% mode-line-default-help-echo 11,328 0% + menu-bar-update-buffers This is taken from just now. It seems like a lot of memory goes there. Given that I have 2Gbs of usage beyond ~40mb reporting I'd suspect something fishy is happening there. And on paper everything looks fine - with single Elisp buffer Emacs reports: 57MiB as reserved for objects, ~30mb of Conses. There is 900Mb of total system usage which makes it top memory eater. For context - I run HiDPI and refresh rate system though (4400x2400 with 60hz - was 144hz before), which might explain why redisplay memory rise is happening quicker than for others. > > FWIW, I'm using Emacs 30.1.90 all the time, with sessions that last > several weeks, and its memory footprint, after leveling at several > hundred MB never grows more, certainly not at the rate you describe. > So either this is a macOS-specific problem, or something else is at > work here (perhaps one of the many packages you have activated?). I'm quite sure that this is the problem with MacOS/NS implementation. I've experienced similar behavior in raw and patched versions and rarely can hold a session for more than 2 days. Usually when Emacs went dead it went dead and that was it, I blamed it on setup, only today caught bloat when I was investigating performance deterioration. (and searching for it the general complain is "well Emacs on MacOS is slower than on Linux"). > Well, for starters please explain why you think it's > redisplay_internal that leaks. Also, if you can try older versions of > Emacs, please see if the same issue exists there. I'm quite positive it does, because I've observed this for at least 2 years. Today it's much better than it was before, but still it bloats. I didn't think about running -Q, and that was simple enough to confirm that: 1,561,924 54% + timer-event-handler 1,185,948 41% - redisplay_internal (C function) 287,011 10% + jit-lock-function 79,104 2% file-remote-p 13,312 0% + kill-this-buffer-enabled-p 8,184 0% mode-line-default-help-echo Usage is 230MiB of memory, reported 5MiB. leaks app (MacOS malloc leak tracer) reports barely 229kb of leaked memory and it reports 37MiB malloced out of 139MiB (usage dropped while I was writing this e-mail). Finally - redisplay_internal is the only place I saw memory going out (and just noticed that redisplay itself is good enough to start GC every couple seconds - 17GCs over 10s test period using -Q instance). > > And finally, what version of Emacs are you using and how did you build > it? Is that Emacs 30.1.90 pretest built from the pretest tarball, or > is it something else? MacOS built with emacs-plus - built through Homebrew from emacs-30 branch right now, but I've seen this performance degredation over time on emacs-mac and emacs through MacPorts. Best, Przemysław Alexander Kamiński --=_MailMate_00503FBC-C382-443C-87A9-1053E89B82BF_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 15 Jul 2025, at 14:23, Eli Zaretskii wrote:

Given the above description, why di= d you decide the leak is in
redisplay_internal?

 39,652,925  72% - redisplay_internal (C=
 function)
  1,797,080   3%  + eval
    279,056   0%  + jit-lock-function
     66,632   0%  + which-key--hide-popup-on-frame-size-change
     24,752   0%    mode-line-default-help-echo
     11,328   0%  + menu-bar-update-buffers

This is taken from just now. It seems like a lot of memor= y goes there. Given that I have 2Gbs of usage beyond ~40mb reporting I'd = suspect something fishy is happening there.

And on paper everything looks fine - with single Elisp bu= ffer Emacs reports: 57MiB as reserved for objects, ~30mb of Conses. There= is 900Mb of total system usage which makes it top memory eater.

For context - I run HiDPI and refresh rate system though = (4400x2400 with 60hz - was 144hz before), which might explain why redispl= ay memory rise is happening quicker than for others.

FWIW, I'm using Emacs 30.1.90 all t= he time, with sessions that last
several weeks, and its memory footprint, after leveling at several
hundred MB never grows more, certainly not at the rate you describe.
So either this is a macOS-specific problem, or something else is at
work here (perhaps one of the many packages you have activated?).

I'm quite sure that this is the problem with MacOS/NS imp= lementation.

I've experienced similar behavior in raw and patched vers= ions and rarely can hold a session for more than 2 days. Usually when Ema= cs went dead it went dead and that was it, I blamed it on setup, only tod= ay caught bloat when I was investigating performance deterioration. (and = searching for it the general complain is "well Emacs on MacOS is slo= wer than on Linux").

Well, for starters please explain w= hy you think it's
redisplay_internal that leaks. Also, if you can try older versions of
Emacs, please see if the same issue exists there.

I'm quite positive it does, because I've observed this fo= r at least 2 years. Today it's much better than it was before, but still = it bloats. I didn't think about running -Q, and that was simple enough to= confirm that:

  1,561,924  54% + timer-event-handler
  1,185,948  41% - redisplay_internal (C function)
    287,011  10%  + jit-lock-function
     79,104   2%    file-remote-p
     13,312   0%  + kill-this-buffer-enabled-p
      8,184   0%    mode-line-default-help-echo

Usage is 230MiB of memory, reported 5MiB. leaks app (MacO= S malloc leak tracer) reports barely 229kb of leaked memory and it report= s 37MiB malloced out of 139MiB (usage dropped while I was writing this e-= mail). Finally - redisplay_internal is the only place I saw memory going = out (and just noticed that redisplay itself is good enough to start GC ev= ery couple seconds - 17GCs over 10s test period using -Q instance).

And finally, what version of Emacs = are you using and how did you build
it? Is that Emacs 30.1.90 pretest built from the pretest tarball, or
is it something else?

MacOS built with emacs-plus - built through Homebrew from= emacs-30 branch right now, but I've seen this performance degredation ov= er time on emacs-mac and emacs through MacPorts.

Best,
Przemys=C5=82aw Alexander Kami=C5=84ski

--=_MailMate_00503FBC-C382-443C-87A9-1053E89B82BF_=-- From unknown Sun Jul 20 11:23:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Jul 2025 13:31:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79023 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Cc: 79023@debbugs.gnu.org Received: via spool by 79023-submit@debbugs.gnu.org id=B79023.1752586245706 (code B ref 79023); Tue, 15 Jul 2025 13:31:04 +0000 Received: (at 79023) by debbugs.gnu.org; 15 Jul 2025 13:30:45 +0000 Received: from localhost ([127.0.0.1]:41225 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ubfk3-0000B6-2r for submit@debbugs.gnu.org; Tue, 15 Jul 2025 09:30:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36212) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ubfjx-00008n-DR for 79023@debbugs.gnu.org; Tue, 15 Jul 2025 09:30:40 -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 ) id 1ubfjr-0003fL-5S; Tue, 15 Jul 2025 09:30:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=viaeGmoHguGMdD720YBWwEXpRHha0MrXJmawlszEonk=; b=GpTu67UeM4iIlEcClS77 O9eapNJjOUTdhtDosM8pzosjB8AU5QFcO7akVfRVetxpoOx4y6S2pwfVXywzrmMJE7cGBgniSlV2j 36pRcPuZOIhyn5s4mxWTQquW/9/iyH1GwoB4FmB6X2w4KlhLI+FCY06kXFwa5tUV3SB9kzAuDugyT iEIGMTmFoX6WVfARVFrNj9UEOARDch/WfEIdjM23DnEKTc8ijFycQdAwPTzXb83RvYa355lvID4u6 9KUY5XUJ9NzcGIQ26jAvAFwK6fjNw/i0eyVC1sagUpg/qSAal/3N02vphoVToYY3o1XwxVQcpH645 zoLl2Ka/gf2Omw==; Date: Tue, 15 Jul 2025 16:30:23 +0300 Message-Id: <86frexk2ds.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <113CE362-63BF-4F13-845C-1DB8F6D8580C@kaminski.se> (przemyslaw@kaminski.se) References: <5BA8A8B9-96CB-4823-836B-49CEBED77CEF@kaminski.se> <86ldopk5hq.fsf@gnu.org> <113CE362-63BF-4F13-845C-1DB8F6D8580C@kaminski.se> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Przemysław Alexander Kamiński > > Cc: 79023@debbugs.gnu.org > Date: Tue, 15 Jul 2025 15:01:55 +0200 > > On 15 Jul 2025, at 14:23, Eli Zaretskii wrote: > > Given the above description, why did you decide the leak is in > redisplay_internal? > > 39,652,925 72% - redisplay_internal (C function) > 1,797,080 3% + eval > 279,056 0% + jit-lock-function > 66,632 0% + which-key--hide-popup-on-frame-size-change > 24,752 0% mode-line-default-help-echo > 11,328 0% + menu-bar-update-buffers > > This is taken from just now. It seems like a lot of memory goes there. Given that I have 2Gbs of usage > beyond ~40mb reporting I'd suspect something fishy is happening there. This is not relevant. The so-called "memory profiler" doesn't profile memory usage, it just uses calls to memory-allocation functions as an opportunity to profile Emacs. So what your profile says is that redisplay_internal was used a lot, but not that there's a memory leak in it. > FWIW, I'm using Emacs 30.1.90 all the time, with sessions that last > several weeks, and its memory footprint, after leveling at several > hundred MB never grows more, certainly not at the rate you describe. > So either this is a macOS-specific problem, or something else is at > work here (perhaps one of the many packages you have activated?). > > I'm quite sure that this is the problem with MacOS/NS implementation. Then let's hear from other macOS users: does anyone else who uses Emacs on macOS have similar experience wrt the Emacs memory footprint? In any case, almost all of the code in redisplay_internal is not macOS specific, so if there's a memory leak there, it is unlikely to affect only the macOS build of Emacs. > 1,561,924 54% + timer-event-handler > 1,185,948 41% - redisplay_internal (C function) > 287,011 10% + jit-lock-function > 79,104 2% file-remote-p > 13,312 0% + kill-this-buffer-enabled-p > 8,184 0% mode-line-default-help-echo > > Usage is 230MiB of memory, reported 5MiB. leaks app (MacOS malloc leak tracer) reports barely 229kb of > leaked memory and it reports 37MiB malloced out of 139MiB (usage dropped while I was writing this e-mail). > Finally - redisplay_internal is the only place I saw memory going out (and just noticed that redisplay itself is > good enough to start GC every couple seconds - 17GCs over 10s test period using -Q instance). See above: your interpretation of the "memory profile" is wrong. In particular, this profile cannot tell us whether we allocate more memory than we free. > And finally, what version of Emacs are you using and how did you build > it? Is that Emacs 30.1.90 pretest built from the pretest tarball, or > is it something else? > > MacOS built with emacs-plus - built through Homebrew from emacs-30 branch right now, but I've seen this > performance degredation over time on emacs-mac and emacs through MacPorts. Thanks. From unknown Sun Jul 20 11:23:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) Resent-From: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Jul 2025 13:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79023 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 79023@debbugs.gnu.org Received: via spool by 79023-submit@debbugs.gnu.org id=B79023.175258755910031 (code B ref 79023); Tue, 15 Jul 2025 13:53:01 +0000 Received: (at 79023) by debbugs.gnu.org; 15 Jul 2025 13:52:39 +0000 Received: from localhost ([127.0.0.1]:41387 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ubg5G-0002bf-1x for submit@debbugs.gnu.org; Tue, 15 Jul 2025 09:52:38 -0400 Received: from fhigh-a3-smtp.messagingengine.com ([103.168.172.154]:60529) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ubg56-0002b9-EC for 79023@debbugs.gnu.org; Tue, 15 Jul 2025 09:52:30 -0400 Received: from phl-compute-03.internal (phl-compute-03.phl.internal [10.202.2.43]) by mailfhigh.phl.internal (Postfix) with ESMTP id 1EF201400205; Tue, 15 Jul 2025 09:52:23 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-03.internal (MEProxy); Tue, 15 Jul 2025 09:52:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaminski.se; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1752587543; x=1752673943; bh=PQNqvM238foa9IyGmzEUjrr0V1+0VCjp267LZjADf/g=; b= PhKwjwMl/lW+Ihq0Bi+ZrmfvX72ezExCURIpRAN62nCF9RrH7cF+Rb1q7lAWiT5V DZ8pZdZWRFdLJJ+PynreLL9HWTQoJ4txK03mpYZ0QWTkqG+XAq0iaD9I0YzpDHHV W4q28cmbZVIDXMlFmhdnw2gPKlartbF3nSjp+2+SGlNkYU+/vAiFq/UwQZ2Eq2Z7 0Q/oguO3zcidCxU1H88ckvkouJ+fmam7AjG3I0BeLxruXe/dMV8C1Dj+zYZbecDu buHegL3ypHw47EWaxsH+Gb8pOJ8BZk5vSoGVwPIB4k158qFaAfO8kT7mns8len7i sNATMgpNCh1FiGnKwB+iNw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1752587543; x= 1752673943; bh=PQNqvM238foa9IyGmzEUjrr0V1+0VCjp267LZjADf/g=; b=b 1zw169SQN1aKGa0ti0+VWQTs+gDM4+f3dXwfPrseduJRq4Dckl3PFqfd2UjOTgLQ J75ORKJ2aKvfmXfS2bR3rHZ1VejG40leop08szVsPcfUDdEnIK6iwCAb/DuvY8Dj +aZGIQ9/ZjHBM3jOVG5gufWKpUgy+RUcPOehy95z7VvGBQQ7tci7RZr3z+oy5adn 6lGD4to/eUUzJwd7vwBvenxtrcqojQSYObU0TiTjMmBgqQU+WYKp4heum8N/Q6uO Br4RvVnBZ2/PNPg9jTqNi5h3xNXHxiEEPqrLAmzkWJjZQa4a3xRaQQiz4V5k9mO5 nR3kpGJyco9NYoXQlCZ0g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdehgeellecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffoffkjghfgggtgfesthhqmhdtredtjeenucfhrhhomheprfhriigvmhih shhlrgifucetlhgvgigrnhguvghrucfmrghmihnkshhkihcuoehprhiivghmhihslhgrfi eskhgrmhhinhhskhhirdhsvgeqnecuggftrfgrthhtvghrnhepjefhgfehffdtuddtvdek gfeuveffleelheffgedtkedtgeeiieekgfehveehtdevnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepphhriigvmhihshhlrgifsehkrghmihhn shhkihdrshgvpdhnsggprhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprhgtph htthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopeejledtvdefseguvggssghu ghhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i08494404:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 15 Jul 2025 09:52:22 -0400 (EDT) From: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Date: Tue, 15 Jul 2025 15:52:20 +0200 X-Mailer: MailMate (1.14r5937) Message-ID: <0B829A49-5464-40AE-B860-3BEC183A3F4B@kaminski.se> In-Reply-To: <86frexk2ds.fsf@gnu.org> References: <5BA8A8B9-96CB-4823-836B-49CEBED77CEF@kaminski.se> <86ldopk5hq.fsf@gnu.org> <113CE362-63BF-4F13-845C-1DB8F6D8580C@kaminski.se> <86frexk2ds.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 15 Jul 2025, at 15:30, Eli Zaretskii wrote: > See above: your interpretation of the "memory profile" is wrong. In > particular, this profile cannot tell us whether we allocate more > memory than we free. > Well this memory profile is something that I would expect to be low and i= rrelevant. I don't have a proof, so marked as a suspicion. I wouldn't be surprised if that'd be something that touched MacOS users o= nly - I've seen plenty of complains about the performance and experienced= it too, but AFAIK we're smaller crowd. Suspicion coms from the fact that= I cannot see where the data is going and leaks tool is reporting low usa= ge, so most likely this is outside of C realm. I've done some extra testing, since I wouldn't be surprised if some relea= se on a string was missing or something. On a fresh instance blinking cur= sor is enough to raise memory usage. 10mb over 4.5mb and garbage- didn't = releaes memory. I think I can reproduce test case and even think what might be the cause,= as I looked around MacOS code for couple of minutes. Best, Przemys=C5=82aw Alexander Kami=C5=84ski From unknown Sun Jul 20 11:23:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) Resent-From: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Jul 2025 06:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79023 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 79023@debbugs.gnu.org Received: via spool by 79023-submit@debbugs.gnu.org id=B79023.175264860131266 (code B ref 79023); Wed, 16 Jul 2025 06:50:02 +0000 Received: (at 79023) by debbugs.gnu.org; 16 Jul 2025 06:50:01 +0000 Received: from localhost ([127.0.0.1]:47603 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ubvxp-00088E-0U for submit@debbugs.gnu.org; Wed, 16 Jul 2025 02:50:01 -0400 Received: from fout-a4-smtp.messagingengine.com ([103.168.172.147]:45587) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ubvxl-00087o-5G for 79023@debbugs.gnu.org; Wed, 16 Jul 2025 02:49:58 -0400 Received: from phl-compute-12.internal (phl-compute-12.phl.internal [10.202.2.52]) by mailfout.phl.internal (Postfix) with ESMTP id D7492EC0110; Wed, 16 Jul 2025 02:49:51 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-12.internal (MEProxy); Wed, 16 Jul 2025 02:49:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaminski.se; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1752648591; x=1752734991; bh=KuRXqDK656 NIOOZk8xgQXU+T9/esRk6qSg3YnJTw7Yo=; b=gsy0IJ1TRIpJXEQAAVuE+LXL/j UjX/fXNvCfMxEvIREjBSCrXSuCV2ZRyQdgEGSy80jnB9lKc/v1KZB9pVr58xmLwU ooHx5KiSxl+ZdWEX/Zv79EIYmfvdcArNha2DlBGnqmb2LlmwSCSG4fCTbnMmybEb SlgZD/Tnx4U3rR/P/VYK7R0BO5XNr/HIoAvirUtZd2JO5uMP2+OisgF1eSzySb4X 8oJtFvlcLVGkfSQxJyo9/bTxcYcULZ8HPq0cIoXG/8pEolH6CiE99H1pOBAin4gh PhRuBW74mCUnJfYX5Yu/6cPmawGYlm8/x13owzpEUTSj8rfofTiVqdLtIIUQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1752648591; x=1752734991; bh=KuRXqDK656NIOOZk8xgQXU+T9/esRk6qSg3 YnJTw7Yo=; b=mwU6W8oWw39qvQivRxQ18dJ5Pc+Go0K2BmYudv8eb4DgQRHhXBb PkM+pd8oF3W+H1VBG1+s24h/OPH3FY4qXiH3ePpek6IR1WKO/PsN3HMZs1VQOfiQ Xxsn/LX762zv73pSVisafcVk6I7/HkR5astZIP7GergXENC+3tTeBBAak0T0nbcv 0AfnTdMbYaJeTl3WRK7aj9GewTNMQRnkkmsKGlIOcAbT12N/24oX1wAX4ILvvUem oa5nU1o44WOGpTwlgf11dSiILyYUUTQA+O0h5Kz2JJVtzBkUtyTgm+P1n63xosAc NxxVdLEz6luJNtlqe7Sxobu0VXr/gK78bEg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdehjedtfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffoffkjghfgggtsehmtdhmreertdejnecuhfhrohhmpefrrhiivghmhihs lhgrficutehlvgigrghnuggvrhcumfgrmhhiknhskhhiuceophhriigvmhihshhlrgifse hkrghmihhnshhkihdrshgvqeenucggtffrrghtthgvrhhnpeeiudejhfdtteegtdefkeef teeuvdegheeiudevkeeiieeljeetkedtvefgkeeiffenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehprhiivghmhihslhgrfieskhgrmhhinhhs khhirdhsvgdpnhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpth htohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtohepjeeltddvfeesuggvsggsuhhg shdrghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i08494404:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 16 Jul 2025 02:49:50 -0400 (EDT) From: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Date: Wed, 16 Jul 2025 08:49:47 +0200 X-Mailer: MailMate (1.14r5937) Message-ID: <74E43489-79B4-4980-8236-0CBFC48E61DD@kaminski.se> In-Reply-To: <0B829A49-5464-40AE-B860-3BEC183A3F4B@kaminski.se> References: <5BA8A8B9-96CB-4823-836B-49CEBED77CEF@kaminski.se> <86ldopk5hq.fsf@gnu.org> <113CE362-63BF-4F13-845C-1DB8F6D8580C@kaminski.se> <86frexk2ds.fsf@gnu.org> <0B829A49-5464-40AE-B860-3BEC183A3F4B@kaminski.se> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_MailMate_FC8BB485-83A2-433D-AECB-0FD81329EABA_=" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=_MailMate_FC8BB485-83A2-433D-AECB-0FD81329EABA_= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yesterday I was able to hookup MacOS' Instruments.app to build Emacs. Too= k some effort to figure out, but once done it was rather easy. I'll make = a short note and publish the steps. Findings: - There are multiple leaks, but most of them are very small in total they= accrue ~1m per minute - The total run was ~2.5m (it slows Emacs down so it's hard to use it all= the time) and I cut off initialization leaks (~1.5m, some related to Too= lbar initialization) - I'm attaching two text files (not sure if it won't bounce) - First one are few example of complex loops - they seem to hit lisp_al= lign_malloc which seems to be related to MacOS-specific code - Second one are root loops. I found few other weird things, e.g. it seems that opening a single midsi= ze buffer processed approx. 2GiB of memory and that a single symbol alloc= ates 1KiB of memory, but I don't think it's the proper thread to discuss = further. Of course there's more but sharing in text form is very difficult. In cas= e someone wants to reproduce by themselves, what it takes is to add task/= debug entitlements (see attached debug.plist) through signing. I had to r= emove com.apple.FinderInfo from emacs-plus build, not sure where it came = from. Build was with debug symbols for easier debugging. Commands I used:= $ xattr -d com.apple.FinderInfo /path/to/Emacs.app $ codesign -s - -v -f --entitlements /path/to/debug.plist /path/to/Emacs.= app After that I started Instruments.app set app bundle for analysis and laun= ched from there. Lot of interesting info, but slows down considerably when constantly prob= ed. I'm somewhat stoked about this because I'm optimization freak and Ema= cs speed on MacOS wasn't something great - it usually deteriorates after = hours - I blamed fancy packages like Marginalia, but if it leaks drops on= small allocations it would make sense why it accelerated the process. Best, Przemys=C5=82aw Alexander Kami=C5=84ski --=_MailMate_FC8BB485-83A2-433D-AECB-0FD81329EABA_= Content-Disposition: attachment; filename=leaks2.txt Content-ID: Content-Type: text/plain; name=leaks2.txt Content-Transfer-Encoding: quoted-printable Root leaks _malloc_zone_malloc_instrumented_or_legacy lmalloc make_blv Fmake_local_variable F636f6d70696c6174696f6e2d6d6f6465_compilation_mode_0 Ffuncall F656d6163732d6c6973702d636f6d70696c6174696f6e2d6d6f6465_emacs_lisp_compil= ation_mode_0 Ffuncall F636f6d702d2d72756e2d6173796e632d776f726b657273_comp__run_async_workers_0= Ffuncall F6e61746976652d2d636f6d70696c652d6173796e63_native__compile_async_0 Ffuncall F6e61746976652d636f6d70696c652d6173796e63_native_compile_async_0 eval_sub Fprogn funcall_lambda Ffuncall Ffuncall F74696d65722d6576656e742d68616e646c6572_timer_event_handler_0 Ffuncall timer_check_2 main start _malloc_zone_malloc_instrumented_or_legacy lmalloc maybe_resize_hash_table hash_put Fputhash Fcomp__install_trampoline F636f6d702d737562722d7472616d706f6c696e652d696e7374616c6c_comp_subr_tramp= oline_install_0 Ffuncall Ffset exec_byte_code Ffuncall F6164766963652d2d6164642d66756e6374696f6e_advice__add_function_0 Ffuncall F6164766963652d616464_advice_add_0 eval_sub Feval_buffer F6c6f61642d776974682d636f64652d636f6e76657273696f6e_load_with_code_conver= sion_0 Ffuncall Feval top_level_run load_comp_unit Feval top_level_run load_comp_unit Feval top_level_run load_comp_unit Feval top_level_run load_comp_unit Ffuncall F74696d65722d6576656e742d68616e646c6572_timer_event_handler_0 Ffuncall main start _malloc_zone_malloc_instrumented_or_legacy lmalloc maybe_resize_hash_table hash_put Fputhash exec_byte_code Ffuncall F6775692d6765742d73656c656374696f6e_gui_get_selection_0 Ffuncall F6775692d2d73656c656374696f6e2d76616c75652d696e7465726e616c_gui__selectio= n_value_internal_0 Ffuncall F6775692d73656c656374696f6e2d76616c7565_gui_selection_value_0 Ffuncall F6b696c6c2d6e6577_kill_new_0 Ffuncall F6b696c6c2d726567696f6e_kill_region_0 Ffuncall F6b696c6c2d776f7264_kill_word_0 Ffuncall F6261636b776172642d6b696c6c2d776f7264_backward_kill_word_0 Ffuncall Ffuncall_interactively Fcall_interactively F636f6d6d616e642d65786563757465_command_execute_0 Ffuncall Fread_from_minibuffer F636f6d706c6574696e672d726561642d64656661756c74_completing_read_default_0= Ffuncall Fcompleting_read F726561642d66696c652d6e616d652d64656661756c74_read_file_name_default_0 Ffuncall F726561642d66696c652d6e616d65_read_file_name_0 Ffuncall F66696e642d66696c652d726561642d61726773_find_file_read_args_0 exec_byte_code Fcall_interactively F636f6d6d616e642d65786563757465_command_execute_0 Ffuncall main start --=_MailMate_FC8BB485-83A2-433D-AECB-0FD81329EABA_= Content-Disposition: attachment; filename=leaks1.txt Content-ID: Content-Type: text/plain; name=leaks1.txt 1 Malloc 544,00 KiB - 1 nodes Complex Cycle _malloc_zone_memalign lisp_align_malloc Fcons Fcopy_sequence timer_check readable_events get_input_pending main start 2 Malloc 544,00 KiB - 1 nodes Complex Cycle _malloc_zone_memalign lisp_align_malloc Fcons Flist Fmatch_data record_unwind_save_match_data autocmp_chars main start 4 Malloc 544,00 KiB - 1 nodes Complex Cycle _malloc_zone_memalign lisp_align_malloc Fcons Flist Fmatch_data record_unwind_save_match_data autocmp_chars Fread_from_minibuffer F636f6d706c6574696e672d726561642d64656661756c74_completing_read_default_0 Ffuncall Fcompleting_read F726561642d66696c652d6e616d652d64656661756c74_read_file_name_default_0 Ffuncall F726561642d66696c652d6e616d65_read_file_name_0 Ffuncall F66696e642d66696c652d726561642d61726773_find_file_read_args_0 exec_byte_code Fcall_interactively F636f6d6d616e642d65786563757465_command_execute_0 Ffuncall main start 5 Malloc 544,00 KiB - 1 nodes Complex Cycle _malloc_zone_memalign lisp_align_malloc Fcons Flist Fmatch_data record_unwind_save_match_data autocmp_chars main start --=_MailMate_FC8BB485-83A2-433D-AECB-0FD81329EABA_= Content-Disposition: attachment; filename=debug.plist Content-ID: Content-Type: text/plain; name=debug.plist Content-Transfer-Encoding: quoted-printable <= plist version=3D"1.0">com.apple.security.get-task-allow<= true/> --=_MailMate_FC8BB485-83A2-433D-AECB-0FD81329EABA_=-- From unknown Sun Jul 20 11:23:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Jul 2025 11:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79023 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Cc: 79023@debbugs.gnu.org Received: via spool by 79023-submit@debbugs.gnu.org id=B79023.175266414328578 (code B ref 79023); Wed, 16 Jul 2025 11:10:02 +0000 Received: (at 79023) by debbugs.gnu.org; 16 Jul 2025 11:09:03 +0000 Received: from localhost ([127.0.0.1]:48421 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uc00V-0007Qs-9s for submit@debbugs.gnu.org; Wed, 16 Jul 2025 07:09:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34956) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uc00R-0007QK-Pl for 79023@debbugs.gnu.org; Wed, 16 Jul 2025 07:09:00 -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 ) id 1uc00K-0006Do-KA; Wed, 16 Jul 2025 07:08:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=qKt8M6ToTpHCsVm4atcLhDh1veFnGBfMOgM7Kmyc88Y=; b=ibDWiaB7CwkE5jHy2Gop i7PukTOWKDIgsxEFx6Zxbf81epvLnRIoTuf+VUSJV1U4+ixW4ld3pQxuNJdpjYolnLyS8sPp4+BPy gQr3nS+rCSNNOiitPFp/M9oahw6yFgfdRrNVXtQPjyC30alsc+XhcXxXxmIMU+bHrEwxeSf4gszv+ 3ZI82yifSborjlc8fqM1lGIwFHjO1HeqJKbtO5Cz+CnmNfGwbqAujZ6toXrHmmjnbQzTGp6xAbLRx /tZpZcMXpn+YQd1LW6b/hzajcjVsdeDc6Gc2KKo9znu2zEou9HHSRuYePMvNfD3aR852WVrgUAAly 2Hs9OdMP5VIDxg==; Date: Wed, 16 Jul 2025 14:08:13 +0300 Message-Id: <865xfsjsv6.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <0B829A49-5464-40AE-B860-3BEC183A3F4B@kaminski.se> (przemyslaw@kaminski.se) References: <5BA8A8B9-96CB-4823-836B-49CEBED77CEF@kaminski.se> <86ldopk5hq.fsf@gnu.org> <113CE362-63BF-4F13-845C-1DB8F6D8580C@kaminski.se> <86frexk2ds.fsf@gnu.org> <0B829A49-5464-40AE-B860-3BEC183A3F4B@kaminski.se> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Przemysław Alexander Kamiński > > Cc: 79023@debbugs.gnu.org > Date: Tue, 15 Jul 2025 15:52:20 +0200 > > I've done some extra testing, since I wouldn't be surprised if some release on a string was missing or something. On a fresh instance blinking cursor is enough to raise memory usage. 10mb over 4.5mb and garbage- didn't releaes memory. Please describe this recipe in more detail, starting from "emacs -Q", so others could try repeating it. Also, please describe how you measure the memory leaks and what are the numbers you see. > I think I can reproduce test case and even think what might be the cause, as I looked around MacOS code for couple of minutes. Please do, and thanks. From unknown Sun Jul 20 11:23:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Jul 2025 12:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79023 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Cc: 79023@debbugs.gnu.org Received: via spool by 79023-submit@debbugs.gnu.org id=B79023.175266740320781 (code B ref 79023); Wed, 16 Jul 2025 12:04:01 +0000 Received: (at 79023) by debbugs.gnu.org; 16 Jul 2025 12:03:23 +0000 Received: from localhost ([127.0.0.1]:48648 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uc0r4-0005P4-Vt for submit@debbugs.gnu.org; Wed, 16 Jul 2025 08:03:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50746) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uc0r1-0005Oi-M1 for 79023@debbugs.gnu.org; Wed, 16 Jul 2025 08:03:20 -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 ) id 1uc0qv-0001U2-5Q; Wed, 16 Jul 2025 08:03:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=FtMJt7ZCk67SBk4g80keG1DA3+3QYYv/GlwWl+qdvB4=; b=l4YYEExo5m71684lE2Fz pz9l5S223X9jI7pvVC8sMP9+hTT0/1FV8uGoAlawvHcb+xODGPjBDJdmcPUnIx68IfLxx7ikmtvtP Qq4ZeKkhLbmcKt79Keq5LeaLCmUFlWz7yQ/2OSv7aIC2DnaeLO5pKcjS/MIeQaUdlbY3eErQBkCmc Z6Qd3fwZLkHi0PdrK4HbabZDr++XSvs/17lCCbc3441k8ykojNBC4Hr1bdFcseoo5DZctmvy9e3mC 780ET7sAoY4VAjGb8Onr3p0od1XuMoKwLAl15ihLjy+FRMDRTU5hRtAx9dLuEe/z8LrfGsviDgK1D Jrj9dX3Hzuhlcg==; Date: Wed, 16 Jul 2025 15:02:40 +0300 Message-Id: <86wm88ibrz.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <74E43489-79B4-4980-8236-0CBFC48E61DD@kaminski.se> (przemyslaw@kaminski.se) References: <5BA8A8B9-96CB-4823-836B-49CEBED77CEF@kaminski.se> <86ldopk5hq.fsf@gnu.org> <113CE362-63BF-4F13-845C-1DB8F6D8580C@kaminski.se> <86frexk2ds.fsf@gnu.org> <0B829A49-5464-40AE-B860-3BEC183A3F4B@kaminski.se> <74E43489-79B4-4980-8236-0CBFC48E61DD@kaminski.se> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Przemysław Alexander Kamiński > > Cc: 79023@debbugs.gnu.org > Date: Wed, 16 Jul 2025 08:49:47 +0200 > > Yesterday I was able to hookup MacOS' Instruments.app to build Emacs. Took some effort to figure out, but once done it was rather easy. I'll make a short note and publish the steps. > > Findings: > - There are multiple leaks, but most of them are very small in total they accrue ~1m per minute > - The total run was ~2.5m (it slows Emacs down so it's hard to use it all the time) and I cut off initialization leaks (~1.5m, some related to Toolbar initialization) > - I'm attaching two text files (not sure if it won't bounce) > - First one are few example of complex loops - they seem to hit lisp_allign_malloc which seems to be related to MacOS-specific code > - Second one are root loops. > > I found few other weird things, e.g. it seems that opening a single midsize buffer processed approx. 2GiB of memory and that a single symbol allocates 1KiB of memory, but I don't think it's the proper thread to discuss further. > > Of course there's more but sharing in text form is very difficult. In case someone wants to reproduce by themselves, what it takes is to add task/debug entitlements (see attached debug.plist) through signing. I had to remove com.apple.FinderInfo from emacs-plus build, not sure where it came from. Build was with debug symbols for easier debugging. Commands I used: > > $ xattr -d com.apple.FinderInfo /path/to/Emacs.app > $ codesign -s - -v -f --entitlements /path/to/debug.plist /path/to/Emacs.app > > After that I started Instruments.app set app bundle for analysis and launched from there. > > Lot of interesting info, but slows down considerably when constantly probed. I'm somewhat stoked about this because I'm optimization freak and Emacs speed on MacOS wasn't something great - it usually deteriorates after hours - I blamed fancy packages like Marginalia, but if it leaks drops on small allocations it would make sense why it accelerated the process. Thanks, but I don't yet understand how to use the information you posted for trying to find the alleged memory leaks. Some questions below. I also am not sure these are real leaks. Emacs Lisp programs trigger memory allocation when they create Lisp objects, but they don't themselves free memory they allocated this way when the objects are no longer needed. Instead, the process known as "garbage collection" (GC) is initiated by Emacs from time to time, and "collects garbage" by finding Lisp objects no longer referenced by any other object, and freeing their memory. (Apologies for the lecture if you already know all that.) Thus, programs that expect memory to be released immediately when the object goes out of scope will think Emacs is a very leaky application, because that's not how Emacs Lisp works. Are you sure the information you collected is not of this kind? > Root leaks > > _malloc_zone_malloc_instrumented_or_legacy > lmalloc > make_blv > Fmake_local_variable > F636f6d70696c6174696f6e2d6d6f6465_compilation_mode_0 > Ffuncall > F656d6163732d6c6973702d636f6d70696c6174696f6e2d6d6f6465_emacs_lisp_compilation_mode_0 > Ffuncall > F636f6d702d2d72756e2d6173796e632d776f726b657273_comp__run_async_workers_0 > Ffuncall > F6e61746976652d2d636f6d70696c652d6173796e63_native__compile_async_0 > Ffuncall > F6e61746976652d636f6d70696c652d6173796e63_native_compile_async_0 > eval_sub > Fprogn > funcall_lambda > Ffuncall > Ffuncall > F74696d65722d6576656e742d68616e646c6572_timer_event_handler_0 > Ffuncall > timer_check_2 > main > start What are "root leaks", and how to interpret the above sequence of function names? > 1 Malloc 544,00 KiB - 1 nodes Complex Cycle > _malloc_zone_memalign > lisp_align_malloc > Fcons > Fcopy_sequence > timer_check > readable_events > get_input_pending > main > start What does the above attempt to tell? Thanks. From unknown Sun Jul 20 11:23:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) Resent-From: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Jul 2025 12:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79023 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 79023@debbugs.gnu.org Received: via spool by 79023-submit@debbugs.gnu.org id=B79023.17526693657557 (code B ref 79023); Wed, 16 Jul 2025 12:37:02 +0000 Received: (at 79023) by debbugs.gnu.org; 16 Jul 2025 12:36:05 +0000 Received: from localhost ([127.0.0.1]:48777 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uc1Mj-0001xp-3F for submit@debbugs.gnu.org; Wed, 16 Jul 2025 08:36:05 -0400 Received: from fhigh-b7-smtp.messagingengine.com ([202.12.124.158]:60433) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uc1Me-0001wx-01 for 79023@debbugs.gnu.org; Wed, 16 Jul 2025 08:36:02 -0400 Received: from phl-compute-04.internal (phl-compute-04.phl.internal [10.202.2.44]) by mailfhigh.stl.internal (Postfix) with ESMTP id 747E97A0114; Wed, 16 Jul 2025 08:35:54 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Wed, 16 Jul 2025 08:35:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaminski.se; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1752669354; x=1752755754; bh=fL9M6h7ZQnuRuZfauWEu+G2v8LfyMPilavt/zc+fAlY=; b= nrBujyM1vMvSO+npKicMksn5DoJelNUQm0RGuMt94KNfKZeHBjUenixxOy5Ucx+U /lLH3Bjqtp7EqwYvw/ZS3isyE1Ituzvb+YUwOBQ75ZPVkricC3BphfB1vWPfkPQE lpjBLY860fq5ev1ua+Y+S3uJx/RITadyNA1+M9ajx4NNBLCkDmu6byzAkxjEJpte vT3MLiTR/Ng2nNFAIEyOWrQhP7+rd0dUEvBpdPPvRmU4uJujZ190cIdbudxaQRLJ ySq8J0XeclTFpPSsezRUb/UX8yfLCuRVX7PjOLXYVNLCpDXoowqz3NBpLiZMNR/K 9Xbk4oFO0qtaSfPgLa7sTg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1752669354; x= 1752755754; bh=fL9M6h7ZQnuRuZfauWEu+G2v8LfyMPilavt/zc+fAlY=; b=f 1RXCflh9pbXFYY8+xyJKKFddmcR9wcr2NTKTJW0c2wCthR0qsULCk7rNXsy5I8jX txXjH3nICXuLfJQ0PeutIxSdQaLOKahEVXCDCp7O14YG1TNQxJQChN1HRItY0FD6 9edD4i20zLPhLVegqegVM8fNDexgYoNf54ixqPypbW0MyqJS1FHse0WsEBadyZbF 9cqgL4SzWtCbMwoougt6kyBeDv2ee1lAaL8uEukNWOGiuY0ZqBtsQLQhRAMAI2yx tsvj+L9Q6d/hlhtsEwT0r/21aQZ2stxNc79hCH5z+ZqpaqdK6fzLQzYwZK8mgUAT KxOvR0LxH59d0saYDW5FA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdehjeejvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffoffkjghfgggtgfesthhqmhdtredtjeenucfhrhhomheprfhriigvmhih shhlrgifucetlhgvgigrnhguvghrucfmrghmihnkshhkihcuoehprhiivghmhihslhgrfi eskhgrmhhinhhskhhirdhsvgeqnecuggftrfgrthhtvghrnhepjefhgfehffdtuddtvdek gfeuveffleelheffgedtkedtgeeiieekgfehveehtdevnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepphhriigvmhihshhlrgifsehkrghmihhn shhkihdrshgvpdhnsggprhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprhgtph htthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopeejledtvdefseguvggssghu ghhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i08494404:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 16 Jul 2025 08:35:53 -0400 (EDT) From: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Date: Wed, 16 Jul 2025 14:35:51 +0200 X-Mailer: MailMate (1.14r5937) Message-ID: <1EDEC015-2F05-42CB-A5BA-C2FA6439859B@kaminski.se> In-Reply-To: <86wm88ibrz.fsf@gnu.org> References: <5BA8A8B9-96CB-4823-836B-49CEBED77CEF@kaminski.se> <86ldopk5hq.fsf@gnu.org> <113CE362-63BF-4F13-845C-1DB8F6D8580C@kaminski.se> <86frexk2ds.fsf@gnu.org> <0B829A49-5464-40AE-B860-3BEC183A3F4B@kaminski.se> <74E43489-79B4-4980-8236-0CBFC48E61DD@kaminski.se> <86wm88ibrz.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > I also am not sure these are real leaks. Emacs Lisp programs trigger > memory allocation when they create Lisp objects, but they don't > themselves free memory they allocated this way when the objects are no > longer needed. Instead, the process known as "garbage collection" > (GC) is initiated by Emacs from time to time, and "collects garbage" > by finding Lisp objects no longer referenced by any other object, and > freeing their memory. (Apologies for the lecture if you already know > all that.) Thus, programs that expect memory to be released > immediately when the object goes out of scope will think Emacs is a > very leaky application, because that's not how Emacs Lisp works. > > Are you sure the information you collected is not of this kind? I'm quite confident it's not the case. Garbage collector doesn't clean it= up. Here's my line of thinking: - 1Gb of Emacs after launch and list-packages is huge (even with hefty co= nfig) - This wouldn't go unnoticed, so most likely isn't the problem of the cor= e code... - I searched before and found also other entries on web which point to Em= acs performance on MacOS - Also I have Emacs config synced to my gaming Windows machine and I didn= 't experience any slowness (it was blazingly fast actually) - All profiling I've done so far look good - Which means something must be happening on MacOS integration The facts for me are: - Emacs is bloating over time and freezes at some point for unknown reaso= ns - Over the time Emacs is more and more slugish, M-x taking 0.7s to think = etc. - After multiple scrupoulous review of config, timers background processe= ss etc. I've noticed that on built Emacs there's allocation for every single blin= k of cursor on screen. Isn't this weird even if that wouldn't leak. I've done more testing today with different build flags and some guesses = that I have: - Some allocated strings aren't marked as autorelease, so they stay - For some reason system doesn't know that this allocated space is no lon= ger used and doesn't GC it - Slowness is caused by immense fragmentation of memory caused by small a= llocations far away from each other - During deallocation hashes aren't deallocated completely - There's missing some MacOS specific call that should be made in order f= or it to optimize - NSEvents are being stopped in flight without deallocation and they keep= references to the memory However, after working in recent months with Zig and C I've been able to = get instrumentation running on MacOS and I'd like to fix it. Best, Przemys=C5=82aw Alexander Kami=C5=84ski From unknown Sun Jul 20 11:23:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) Resent-From: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Jul 2025 12:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79023 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 79023@debbugs.gnu.org Received: via spool by 79023-submit@debbugs.gnu.org id=B79023.175267046011892 (code B ref 79023); Wed, 16 Jul 2025 12:55:01 +0000 Received: (at 79023) by debbugs.gnu.org; 16 Jul 2025 12:54:20 +0000 Received: from localhost ([127.0.0.1]:48854 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uc1eO-00035j-3l for submit@debbugs.gnu.org; Wed, 16 Jul 2025 08:54:20 -0400 Received: from fout-b3-smtp.messagingengine.com ([202.12.124.146]:56211) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uc1eI-000354-7D for 79023@debbugs.gnu.org; Wed, 16 Jul 2025 08:54:17 -0400 Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47]) by mailfout.stl.internal (Postfix) with ESMTP id 60F7D1D00114; Wed, 16 Jul 2025 08:54:08 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-07.internal (MEProxy); Wed, 16 Jul 2025 08:54:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaminski.se; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1752670448; x=1752756848; bh=eUxecgcMsyNX3eMEKmxJzmRqNTVa2TvuBF3+6pxLuZU=; b= gbw5ofNQvmtwlRl0FUhehcTp2I8+viL8Mjm7kILuI63fo6vkC76hGoI6X2ELGDGG sCRSoJZ+JPZmpN/8XfW3b1b9Xu/7ZXUzPRVZr2Qwo9Vc37GB/aciof5xO2h0rJo7 WeM2t4SuDTLdAvwX5ora0czt0tFMPqFmab9FtZU0fdB/JbKGVe7R52w8qHJpDg/b 1/+nxj9UoKiGT7NJozomacEsjjAawsH1Yfc9gB3EeG73hQvn/DQLVrYQPQADJyP/ Rz22NE/b2nrtiR6va2THoD/eLtE+v7NJCJnojRuAQIyfHHManGoL6SqSSvq33J4O 1OK0ov4zes/SVPutdPyl+w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1752670448; x= 1752756848; bh=eUxecgcMsyNX3eMEKmxJzmRqNTVa2TvuBF3+6pxLuZU=; b=T RS2LHX1vCsqFXkKpcQk4vTkL4lVuaTEF8hN0Vk0fW1nZUqQeahdjkdIy0Lir6joO RFwG4rz0pRN8l0KdcWba71mqduY+HYlLCW9+HJvq63aJdFO/31DPs/kVXfkaB7Xa T5W0AMOEru1StKWKKS9LhBtJqru49LJh/pS2DZKBqqjza/sERoicN7Nq4Eeq032z Mpz7G76s7XpQuxYdixzIdk4hlFoMlCWemLOvUimOfhZLsDipw3qq0V3p9m/wAHIZ t23+WJpsf0ZnaoGVBHAWe7nm+hTGGMC9NhPiXJa89UYIQ34qQ/yPCjqxRfzsjWaa hq7t/HNZBjtr047TYV/ew== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdehjeejiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffoffkjghfgggtgfesmhekmherredtjeenucfhrhhomheprfhriigvmhih shhlrgifucetlhgvgigrnhguvghrucfmrghmihnkshhkihcuoehprhiivghmhihslhgrfi eskhgrmhhinhhskhhirdhsvgeqnecuggftrfgrthhtvghrnhephefhveefleevkefghfdt heejjeelgfethfdtgfehgeehffefgefghfeuheffffevnecuffhomhgrihhnpeihohhuth husggvrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepphhriigvmhihshhlrgifsehkrghmihhnshhkihdrshgvpdhnsggprhgtphhtth hopedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdrohhr ghdprhgtphhtthhopeejledtvdefseguvggssghughhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i08494404:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 16 Jul 2025 08:54:07 -0400 (EDT) From: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Date: Wed, 16 Jul 2025 14:54:06 +0200 X-Mailer: MailMate (1.14r5937) Message-ID: In-Reply-To: <865xfsjsv6.fsf@gnu.org> References: <5BA8A8B9-96CB-4823-836B-49CEBED77CEF@kaminski.se> <86ldopk5hq.fsf@gnu.org> <113CE362-63BF-4F13-845C-1DB8F6D8580C@kaminski.se> <86frexk2ds.fsf@gnu.org> <0B829A49-5464-40AE-B860-3BEC183A3F4B@kaminski.se> <865xfsjsv6.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_MailMate_484B6CA2-4E4E-48D2-A9A6-3F56F0A13069_=" Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=_MailMate_484B6CA2-4E4E-48D2-A9A6-3F56F0A13069_= Content-Type: multipart/alternative; boundary="=_MailMate_E75D9595-050A-4ACA-AEF8-1EC6397DC879_=" Content-Transfer-Encoding: 8bit --=_MailMate_E75D9595-050A-4ACA-AEF8-1EC6397DC879_= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 16 Jul 2025, at 13:08, Eli Zaretskii wrote: >> From: Przemysław Alexander Kamiński >> >> Cc: 79023@debbugs.gnu.org >> Date: Tue, 15 Jul 2025 15:52:20 +0200 >> >> I've done some extra testing, since I wouldn't be surprised if some >> release on a string was missing or something. On a fresh instance >> blinking cursor is enough to raise memory usage. 10mb over 4.5mb and >> garbage- didn't releaes memory. > > Please describe this recipe in more detail, starting from "emacs -Q", > so others could try repeating it. Also, please describe how you > measure the memory leaks and what are the numbers you see. > Unfortunatelly there's nothing more I can do, Instruments is strictly GUI app. All text has to be extracted manually. I know it's probably the worst way to do, but I recorded example session with `emacs -Q`. https://www.youtube.com/watch?v=_korzyoMXfY It'd be nice if someone smarter than me and more experienced in MacOS system programming took a look on this, my current line is to have a build pipeline and throw different ideas until I can find something that works. >> I think I can reproduce test case and even think what might be the >> cause, as I looked around MacOS code for couple of minutes. > > Please do, and thanks. I've been able to reproduce by using blinking cursor (setq blink-cursor-blinks 0 blink-cursor-interval 0.1). Attached patch seemed to decrease number of allocations and leaks but it's not enough to make a dent. Best, Przemysław Alexander Kamiński --=_MailMate_E75D9595-050A-4ACA-AEF8-1EC6397DC879_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 16 Jul 2025, at 13:08, Eli Zaretskii wrote:

From: Przemys=C5=82aw Alexander Kami=C5=84ski
<przemyslaw@kaminski.se>
Cc: 79023@debbugs.gnu.org
Date: Tue, 15 Jul 2025 15:52:20 +0200

I've done some extra testing, since I wouldn't be surpris= ed if some release on a string was missing or something. On a fresh insta= nce blinking cursor is enough to raise memory usage. 10mb over 4.5mb and = garbage- didn't releaes memory.

Please describe this recipe in more detail, = starting from "emacs -Q",
so others could try repeating it. Also, please describe how you
measure the memory leaks and what are the numbers you see.


Unfortunatelly there's nothing more I can do, Instruments= is strictly GUI app. All text has to be extracted manually. I know it's = probably the worst way to do, but I recorded example session with emacs -Q.

https://www.youtube.com/watch?v=3D_korzyoMXfY<= /a>

It'd be nice if someone smarter than me and more experien= ced in MacOS system programming took a look on this, my current line is t= o have a build pipeline and throw different ideas until I can find someth= ing that works.

I've been able to reproduce by using blinking cursor (set= q blink-cursor-blinks 0 blink-cursor-interval 0.1).
Attached patch seemed to decrease number of allocations and leaks but it'= s not enough to make a dent.

Best,
Przemys=C5=82aw Alexander Kami=C5=84ski

--=_MailMate_E75D9595-050A-4ACA-AEF8-1EC6397DC879_=-- --=_MailMate_484B6CA2-4E4E-48D2-A9A6-3F56F0A13069_= Content-Disposition: attachment; filename=memleak.patch Content-Type: text/plain; name=memleak.patch Content-Transfer-Encoding: quoted-printable diff --git a/src/nsfont.m b/src/nsfont.m index b8aa6764..f99980b1 100644 --- a/src/nsfont.m +++ b/src/nsfont.m @@ -529,6 +529,10 @@ static void ns_glyph_metrics (struct nsfont_info *fo= nt_info, chars[95] =3D '\0'; = ascii_printable =3D [[NSString alloc] initWithFormat: @"%s", chars= ]; + if (ascii_printable !=3D nil ) + { + [ascii_printable autorelease]; + } } = if (w < (CGFloat) 0.0) --=_MailMate_484B6CA2-4E4E-48D2-A9A6-3F56F0A13069_=-- From unknown Sun Jul 20 11:23:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Jul 2025 13:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79023 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= , Alan Third Cc: 79023@debbugs.gnu.org Received: via spool by 79023-submit@debbugs.gnu.org id=B79023.175267231820157 (code B ref 79023); Wed, 16 Jul 2025 13:26:01 +0000 Received: (at 79023) by debbugs.gnu.org; 16 Jul 2025 13:25:18 +0000 Received: from localhost ([127.0.0.1]:48970 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uc28K-0005Ea-RE for submit@debbugs.gnu.org; Wed, 16 Jul 2025 09:25:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42690) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uc28G-00055a-OG for 79023@debbugs.gnu.org; Wed, 16 Jul 2025 09:25:14 -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 ) id 1uc288-0007bM-KQ; Wed, 16 Jul 2025 09:25:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=pz1L/ZMShhTRdTCdWEcEvVOzPaHqX4FsfXBxSSs6ZLk=; b=jmosY8OUurrmP078jsMO vBgLqOjrUs1cCHShPGO4ttU/ghLffeKowJ6hZw7Ny+5CUr9Q5wGkAeyifAWMlAijHE+vWgHtqHvi7 v47g2Y0DOk01zolaZJGOvzRaqAdxoCDzN3V4Yhhx9LbkCqetO+Y4cx5lHofwqxr9oQO1wm2PhzOVY 7fzin7h5Ie8/5L+7+Xd5muz/sZwfqjov8wIvqAm9bxHS966jOcRsPGOaKLjvKRROXFqU01dO1w9+o FoSQghNXF4H6radF/mBrIQElLZpUBbsa/Lf2Yr+F1bRRNejVs+Li3MWsdWKeIqeZnl9UpOAy42chi PZmjQ4oS6pNwSw==; Date: Wed, 16 Jul 2025 16:24:41 +0300 Message-Id: <86ple0i7za.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <1EDEC015-2F05-42CB-A5BA-C2FA6439859B@kaminski.se> (przemyslaw@kaminski.se) References: <5BA8A8B9-96CB-4823-836B-49CEBED77CEF@kaminski.se> <86ldopk5hq.fsf@gnu.org> <113CE362-63BF-4F13-845C-1DB8F6D8580C@kaminski.se> <86frexk2ds.fsf@gnu.org> <0B829A49-5464-40AE-B860-3BEC183A3F4B@kaminski.se> <74E43489-79B4-4980-8236-0CBFC48E61DD@kaminski.se> <86wm88ibrz.fsf@gnu.org> <1EDEC015-2F05-42CB-A5BA-C2FA6439859B@kaminski.se> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Przemysław Alexander Kamiński > > Cc: 79023@debbugs.gnu.org > Date: Wed, 16 Jul 2025 14:35:51 +0200 > > > I also am not sure these are real leaks. Emacs Lisp programs trigger > > memory allocation when they create Lisp objects, but they don't > > themselves free memory they allocated this way when the objects are no > > longer needed. Instead, the process known as "garbage collection" > > (GC) is initiated by Emacs from time to time, and "collects garbage" > > by finding Lisp objects no longer referenced by any other object, and > > freeing their memory. (Apologies for the lecture if you already know > > all that.) Thus, programs that expect memory to be released > > immediately when the object goes out of scope will think Emacs is a > > very leaky application, because that's not how Emacs Lisp works. > > > > Are you sure the information you collected is not of this kind? > > I'm quite confident it's not the case. Garbage collector doesn't clean it up. How do you see that GC doesn't clean up? > Here's my line of thinking: > - 1Gb of Emacs after launch and list-packages is huge (even with hefty config) Sorry, I don't understand what that means. Are you saying that you load many packages at startup? How many? Could we please start the measurements from "emacs -Q", to avoid potential influence of too many unknowns? I've just left "emacs -Q" running for 10 minutes, after setting blink-cursor-blinks to zero (so it keeps blinking indefinitely), and not only did it not grow in memory, it _freed_ some memory. > - This wouldn't go unnoticed, so most likely isn't the problem of the core code... > - I searched before and found also other entries on web which point to Emacs performance on MacOS > - Also I have Emacs config synced to my gaming Windows machine and I didn't experience any slowness (it was blazingly fast actually) > - All profiling I've done so far look good > - Which means something must be happening on MacOS integration It's possible that on macOS there's some leak, but we need a much more specific information to find where it happens. Just looking at the memory allocation calls will never tell us anything useful, because Emacs calls malloc _a_lot_. > The facts for me are: > - Emacs is bloating over time and freezes at some point for unknown reasons > - Over the time Emacs is more and more slugish, M-x taking 0.7s to think etc. > - After multiple scrupoulous review of config, timers background processess etc. I'm not arguing against the facts. > I've noticed that on built Emacs there's allocation for every single blink of cursor on screen. Isn't this weird even if that wouldn't leak. No, it isn't weird at all. Cursor-blinking in Emacs is not a terminal function, it is Emacs actively turning the cursor off and on again, every 0.5 sec. To do that, it runs a 2 Hz timer, which expires every 0.5 sec, then turns the cursor on or off, and then computes the time it should expire next. All these actions allocate memory (which is then freed, some of it immediately and some later, via GC). > I've done more testing today with different build flags and some guesses that I have: > - Some allocated strings aren't marked as autorelease, so they stay What do you mean by "marked autorelease"? Lisp strings are released by GC when they are no longer referenced from any other object. There's no such thing as "autorelease strings" in Emacs. > - For some reason system doesn't know that this allocated space is no longer used and doesn't GC it How do you see that? And which space is it, allocated by what functions? > - Slowness is caused by immense fragmentation of memory caused by small allocations far away from each other Emacs relies on the system malloc to be able to avoid fragmentation. Where that is not guaranteed (such as on MS-Windows), Emacs has its own replacements for the system malloc, which avoid fragmentation. > - During deallocation hashes aren't deallocated completely Which hashes are those? > - There's missing some MacOS specific call that should be made in order for it to optimize Which calls, and where are they missing? > - NSEvents are being stopped in flight without deallocation and they keep references to the memory This should be addressed by some macOS expert. Alan, can you help here? From unknown Sun Jul 20 11:23:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) Resent-From: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Jul 2025 14:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79023 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Alan Third , 79023@debbugs.gnu.org Received: via spool by 79023-submit@debbugs.gnu.org id=B79023.175267537132715 (code B ref 79023); Wed, 16 Jul 2025 14:17:01 +0000 Received: (at 79023) by debbugs.gnu.org; 16 Jul 2025 14:16:11 +0000 Received: from localhost ([127.0.0.1]:49968 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uc2va-0008Vb-DH for submit@debbugs.gnu.org; Wed, 16 Jul 2025 10:16:10 -0400 Received: from fout-b3-smtp.messagingengine.com ([202.12.124.146]:50401) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uc2vU-0008Ua-CX for 79023@debbugs.gnu.org; Wed, 16 Jul 2025 10:16:08 -0400 Received: from phl-compute-03.internal (phl-compute-03.phl.internal [10.202.2.43]) by mailfout.stl.internal (Postfix) with ESMTP id A36931D00042; Wed, 16 Jul 2025 10:15:58 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-03.internal (MEProxy); Wed, 16 Jul 2025 10:15:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaminski.se; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1752675358; x=1752761758; bh=k74Xr7hpuRJIvcLRDXHv17vkCWEY8CZgrWdyZ4Nd3fw=; b= NQ3539h+A9P7gvMwc7dbgX1Ihw+mztrGGwYYX3M5PMiUjXfpvNsv5RAwF3LAvnTA 6DK7hFi7EdxyGnr3XR4bAPCP1s6xH6IBg/eiIixwTJC9ar0BTUQK59LCGqpdBiV3 pr76u9hV3Zda5H9fTn1JqOhIs3nhZzHbK3XYIH1GsmTtDNychbLui0vDDiptNXTQ /+qw0CzDziYBntHwoB/aQrOXb0CZcmdYKtRrgQQWH3w05PtvGNFOw/mmyZ/UNHaR 4k+9MEXRvOE6p9FOcH5tVIe+ZPTfZBDoMZfJVJuETH6TU6AjfX+22Z3BOnp7VpVU n361hW9Rns7WAWaN7e27Dg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1752675358; x= 1752761758; bh=k74Xr7hpuRJIvcLRDXHv17vkCWEY8CZgrWdyZ4Nd3fw=; b=I 1fd3L0FYEZxFq87WLB6HA6I+1eoZnGsHeMPKPE9boV34VqGTTcQPMC4zFIUFFB1D 7YXQVuiwTsOQR6lUzMJPfzxxx5Pb+Xmo4VJve8FBT6SeyNP/l9DzOCAMYNycHwoV FPIZsA8t7FNffpNk0mry/cHKiwcV37d1qDKnYVjR4iTUDA/gbcTxvyop72FDdzLy bjUI9dhw2iBgundYvfO9Ojh6O1f9OufdAJV9iX//ZWitXkkswOLxGA13fZwG8tkR ejQb6NrDx1Et6ImPRgi1mOQGDWiiL4uz/4Jxaa7hfE/bNgyl5WCQaHMwbvQe+yIi RIYj3mbnDSuE6sviafpvQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdehjeelvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffoffkjghfgggtgfesthhqmhdtredtjeenucfhrhhomheprfhriigvmhih shhlrgifucetlhgvgigrnhguvghrucfmrghmihnkshhkihcuoehprhiivghmhihslhgrfi eskhgrmhhinhhskhhirdhsvgeqnecuggftrfgrthhtvghrnhepjefhgfehffdtuddtvdek gfeuveffleelheffgedtkedtgeeiieekgfehveehtdevnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepphhriigvmhihshhlrgifsehkrghmihhn shhkihdrshgvpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpohhuthdprhgtph htthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopegrlhgrnhesihguihhotgih rdhorhhgpdhrtghpthhtohepjeeltddvfeesuggvsggsuhhgshdrghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i08494404:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 16 Jul 2025 10:15:57 -0400 (EDT) From: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Date: Wed, 16 Jul 2025 16:15:54 +0200 X-Mailer: MailMate (1.14r5937) Message-ID: <2675FB79-2BE4-4808-9CFA-1DD33F9F643F@kaminski.se> In-Reply-To: <86ple0i7za.fsf@gnu.org> References: <5BA8A8B9-96CB-4823-836B-49CEBED77CEF@kaminski.se> <86ldopk5hq.fsf@gnu.org> <113CE362-63BF-4F13-845C-1DB8F6D8580C@kaminski.se> <86frexk2ds.fsf@gnu.org> <0B829A49-5464-40AE-B860-3BEC183A3F4B@kaminski.se> <74E43489-79B4-4980-8236-0CBFC48E61DD@kaminski.se> <86wm88ibrz.fsf@gnu.org> <1EDEC015-2F05-42CB-A5BA-C2FA6439859B@kaminski.se> <86ple0i7za.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > Sorry, I don't understand what that means. Are you saying that you > load many packages at startup? How many? > > Could we please start the measurements from "emacs -Q", to avoid > potential influence of too many unknowns? Probably around 100-200, and it's mostly popular setup: LSP/Vertico+frien= ds some theme and fonts. This shouldn't be 1Gb at start right? > > I've just left "emacs -Q" running for 10 minutes, after setting > blink-cursor-blinks to zero (so it keeps blinking indefinitely), and > not only did it not grow in memory, it _freed_ some memory. Are you on MacOS? Because that patch that I made fixed the issue for me a= s well (the one with autorelease). If you are than it would mean that issue might be deeper and be caused by= gcc installation... that'd be fun.. > It's possible that on macOS there's some leak, but we need a much more > specific information to find where it happens. Just looking at the > memory allocation calls will never tell us anything useful, because > Emacs calls malloc _a_lot_. I know, trying to make it happen. IMO "emacs -Q" won't help because if le= ak happens on local object allocation or event handling there won't be ou= tliers. I can confirm at least one thing though - if window isn't drawn, Instrume= nts doesn't report any leaks. >> I've noticed that on built Emacs there's allocation for every single b= link of cursor on screen. Isn't this weird even if that wouldn't leak. > > No, it isn't weird at all. (...) All these actions allocate memory (wh= ich is > then freed, some of it immediately and some later, via GC). > I'm spoiled by my recent work with Zig because and would expect that ther= e's pool or arena, I'll look into this when I can shuffle the code instea= d of rebuilding it from scratch. >> I've done more testing today with different build flags and some guess= es that I have: >> - Some allocated strings aren't marked as autorelease, so they stay > > What do you mean by "marked autorelease"? Lisp strings are released > by GC when they are no longer referenced from any other object. > There's no such thing as "autorelease strings" in Emacs. Not in Emacs, but it's in Cocoa. As far as I know it's using ARC. Some NS= Strings are allocated in integration module. Since this allocation is outside of normal malloc I wouldn't expect it to= be GC by Emacs (still on my theory that the bug sits in integration code= ). I'm not a Objective-C developer, but some NSStrings are marked with "auto= release" upon creation and some are not - I'm suspicious. Could it be the cause if that'd be single glyph that can't be released...= >> - For some reason system doesn't know that this allocated space is no = longer used and doesn't GC it > How do you see that? And which space is it, allocated by what > functions? After 4 hours of usage I have 2Gb of memory kept. Garbage collection does= n't touch it at all. I don't know what exactly because unfortunatelly I didn't run Emacs long = enough for it to gather data. >> - Slowness is caused by immense fragmentation of memory caused by smal= l allocations far away from each other > > Emacs relies on the system malloc to be able to avoid fragmentation. > Where that is not guaranteed (such as on MS-Windows), Emacs has its > own replacements for the system malloc, which avoid fragmentation. I'm wondering if the build system that _most_ MacOS builds are using aren= 't at fault and use gcc's one. It would make sense - on Windows Emacs feels snappier than on MacOS.. >> - During deallocation hashes aren't deallocated completely > Which hashes are those? I was looking at hash_table_alloc_bytes (ptrdiff_t nbytes) ATTRIBUTE_MALLOC_SIZE ((1)); hash_table_free_bytes (void *p, ptrdiff_t nbytes); There seems to be some calculation during release, maybe something goes w= rong? >> - There's missing some MacOS specific call that should be made in orde= r for it to optimize > Which calls, and where are they missing? Probably Alan (hi!) could help; I have no idea. But I know what happens w= hen you don't type "sync" before you pull out the floppy ;-) Best, Przemys=C5=82aw Alexander Kami=C5=84ski From unknown Sun Jul 20 11:23:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Jul 2025 14:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79023 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Cc: Eli Zaretskii , 79023@debbugs.gnu.org Received: via spool by 79023-submit@debbugs.gnu.org id=B79023.17526771387485 (code B ref 79023); Wed, 16 Jul 2025 14:46:02 +0000 Received: (at 79023) by debbugs.gnu.org; 16 Jul 2025 14:45:38 +0000 Received: from localhost ([127.0.0.1]:50085 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uc3O5-0001we-7O for submit@debbugs.gnu.org; Wed, 16 Jul 2025 10:45:37 -0400 Received: from dane.soverin.net ([2a10:de80:1:4092:b9e9:2295:0:1]:53771) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uc3Ny-0001wF-S9 for 79023@debbugs.gnu.org; Wed, 16 Jul 2025 10:45:34 -0400 Received: from smtp.soverin.net (c04smtp-lb01.int.sover.in [10.10.4.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4bhzPG4fH0zyXn; Wed, 16 Jul 2025 14:45:22 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.100]) by soverin.net (Postfix) with ESMTPSA id 4bhzPG0ZfJzM2; Wed, 16 Jul 2025 14:45:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1752677122; bh=Es4z0Pyk6VOui8jPDKKp9O43u3KIRjnFIwpAnmuocp8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AEYQCtIW8ZDqm9fAHbpLUE0bK6snndAgFmLP8OggM66LjqT5fQIDLqeOcJoHY8tPZ Z3GjeHjvZ6H5v302mD28DPcyNvGIET9YtknGBJjvLWS2GGxekd2t9XpRM3i7KqIt7s rGRRA2/bBa/OPKsuvxlq/1bo8ob9M88XiFe4mUgoLKcjwnUR+AoZidvSpd1xTElhyX 8o2UZgU3iU3JIiGJexVZMWsNeH93mKFkodrByqd5fZx7SahR9Gz+Ct4kxYgtc55Bzw 6JW1GJpmmbKk1WAvublcqBxvmdW4FQczLtsHoH73TtqsY/qakknG/sj0vlnotDUaBx vm6ghHT3SF/hQ== X-CM-Envelope: MS4xfPxzzqzG5n48VQK/5BUe2gq7WDbgf1GWHrPpP8ypA+PKSpK6/ZHYAIvDbVVfnSlT+fb6GWneLPMyUCJHHuaJ5UoE059Symgd4Dr8TLH5zUnDRr31Ywkr Hmwgr7j2Ql8rlSEMRq8I15YbGxGoS3gBPKwCDM/p1EJq8KizPAt8PdA562U4f5lMUwyk1Eogw9hcJyGVOQ4vdrRGe7FduRUVer40+HOPMAKV08lZKQ15PO+N Qq/u6w89uXu1+1CrrlQkRNN5j3Rh9nokQmBEAZNA8g8= X-CM-Analysis: v=2.4 cv=d/oPyQjE c=1 sm=1 tr=0 ts=6877bb02 a=UbsBXRcqaZ6D9kgPt/Dvnw==:617 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=Wb1JkmetP80A:10 a=ltFRoOhP_VUU5ymx2FUA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=ZXulRonScM0A:10 a=9MSFP0l5Dcwi9NrB_JPx:22 Received: from localhost (faroe.holly.idiocy.org [local]) by faroe.holly.idiocy.org (OpenSMTPD) with ESMTPA id b69ccf7c; Wed, 16 Jul 2025 14:45:21 +0000 (UTC) Date: Wed, 16 Jul 2025 15:45:21 +0100 From: Alan Third Message-ID: Mail-Followup-To: Alan Third , =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= , Eli Zaretskii , 79023@debbugs.gnu.org References: <5BA8A8B9-96CB-4823-836B-49CEBED77CEF@kaminski.se> <86ldopk5hq.fsf@gnu.org> <113CE362-63BF-4F13-845C-1DB8F6D8580C@kaminski.se> <86frexk2ds.fsf@gnu.org> <0B829A49-5464-40AE-B860-3BEC183A3F4B@kaminski.se> <865xfsjsv6.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spampanel-Class: ham X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Wed, Jul 16, 2025 at 02:54:06PM +0200, Przemysław Alexander Kamiński wrote: > > diff --git a/src/nsfont.m b/src/nsfont.m > index b8aa6764..f99980b1 100644 > --- a/src/nsfont.m > +++ b/src/nsfont.m > @@ -529,6 +529,10 @@ static void ns_glyph_metrics (struct nsfont_info *font_info, > chars[95] = '\0'; > > ascii_printable = [[NSString alloc] initWithFormat: @"%s", chars]; > + if (ascii_printable != nil ) > + { > + [ascii_printable autorelease]; > + } > } > > if (w < (CGFloat) 0.0) Is this the full patch? Unfortunately nsfont.m isn't used on macos, it's only for GNUstep. Also I'm pretty sure that when using alloc the object's lifetime is restricted to the calling function, you need to retain the object if you want to keep it. I'm not saying we definitely don't make a mistake somewhere with retain/release, but this probably isn't it. -- Alan Third From unknown Sun Jul 20 11:23:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) Resent-From: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Jul 2025 14:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79023 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Third Cc: Eli Zaretskii , 79023@debbugs.gnu.org Received: via spool by 79023-submit@debbugs.gnu.org id=B79023.17526774978742 (code B ref 79023); Wed, 16 Jul 2025 14:52:02 +0000 Received: (at 79023) by debbugs.gnu.org; 16 Jul 2025 14:51:37 +0000 Received: from localhost ([127.0.0.1]:50101 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uc3Ts-0002Gw-P8 for submit@debbugs.gnu.org; Wed, 16 Jul 2025 10:51:37 -0400 Received: from fhigh-b1-smtp.messagingengine.com ([202.12.124.152]:40359) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uc3Tp-0002Gd-TA for 79023@debbugs.gnu.org; Wed, 16 Jul 2025 10:51:34 -0400 Received: from phl-compute-12.internal (phl-compute-12.phl.internal [10.202.2.52]) by mailfhigh.stl.internal (Postfix) with ESMTP id 4DB577A00B5; Wed, 16 Jul 2025 10:51:28 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-12.internal (MEProxy); Wed, 16 Jul 2025 10:51:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaminski.se; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1752677488; x=1752763888; bh=FcEdZHqKWfpJsmTy0MC6H+TvoyBYb+uNBzSEFXuopGA=; b= dRvDWp3kvs1EetU3z2QKY3nhsJ60gbtl6estB5cI8ZSWxLl2qb+LiOhZyTUXGmSj BMXY05342/Q4sYn6FPI4QZoM89IkZWQpOxIBRlFTw+5/rO6vCixNCbQctkhSsrhQ Q9oP1Cqx36KIg3mimlF1Up9U4Ex/Yu2hvB4z7GYFFsHmtoIILgK1A2E34TRMcURs hOO7bUG6M6ItW3BQHFmtdbYZMpC7ALIEdBoGZJWcZUdYTY+eUJU34V64gBcFwyhz yJKBOAQeFMehU6zyktsNbUQNMwwStSBkWQi1lS0xlR0j/G9GB8S/zhd9d/4+0Ly/ 2hae94fuIZiLrjQPK8g3MQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1752677488; x= 1752763888; bh=FcEdZHqKWfpJsmTy0MC6H+TvoyBYb+uNBzSEFXuopGA=; b=P wPMZAbC9vo9fi3IwgErFYobunHu5bTx1PvzK0VOecHMXjePX5EV+b9Jy3e5PHwU/ T0zhFsbRg398pBitUnW0HLKAI/AKtCiVHFtZ017Z3krLh3iSLHR6eRB5ZAgFp0BW tZL1Pn7r+VK62qQU1YkH/IKLHyzxxvlzXr0Y/vDhv2Y2lDGds5K3S/GBLXWD4sKn 3b5yWTrTUwxTmrad5b7U7xxOCbrbl/vCt4JwXp9G59AsjxEkfxTXhr0otIFlRtIP HUigKrjQ/wSwUHCkM/KsRW9/PoEm3P2l/2uDN6nHq0/Rqc2wRotSVx+2/tbDlJJx EcKqBct53aE046X0hHjpw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdehjeellecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffoffkjghfgggtgfesthekmhdtredtjeenucfhrhhomheprfhriigvmhih shhlrgifucetlhgvgigrnhguvghrucfmrghmihnkshhkihcuoehprhiivghmhihslhgrfi eskhgrmhhinhhskhhirdhsvgeqnecuggftrfgrthhtvghrnhepuefhudeghfefjefgfffg heegvdfgffffgeekveejuefggffgieeiueegleffuddvnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepphhriigvmhihshhlrgifsehkrghmihhn shhkihdrshgvpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpohhuthdprhgtph htthhopegrlhgrnhesihguihhotgihrdhorhhgpdhrtghpthhtohepvghlihiisehgnhhu rdhorhhgpdhrtghpthhtohepjeeltddvfeesuggvsggsuhhgshdrghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i08494404:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 16 Jul 2025 10:51:27 -0400 (EDT) From: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Date: Wed, 16 Jul 2025 16:51:24 +0200 X-Mailer: MailMate (1.14r5937) Message-ID: In-Reply-To: References: <5BA8A8B9-96CB-4823-836B-49CEBED77CEF@kaminski.se> <86ldopk5hq.fsf@gnu.org> <113CE362-63BF-4F13-845C-1DB8F6D8580C@kaminski.se> <86frexk2ds.fsf@gnu.org> <0B829A49-5464-40AE-B860-3BEC183A3F4B@kaminski.se> <865xfsjsv6.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > Is this the full patch? Unfortunately nsfont.m isn't used on macos, > it's only for GNUstep. Yup :) > Also I'm pretty sure that when using alloc the object's lifetime is > restricted to the calling function, you need to retain the object if > you want to keep it. It's marked as a static pointer, so I believe it wouldn't be cleared. Yet i'm completely out of my water here. > I'm not saying we definitely don't make a mistake somewhere with > retain/release, but this probably isn't it. Even if it was then it wasn't impactful anyway, so I wouldn't focus on that at all. Best, Przemysław Alexander Kamiński From unknown Sun Jul 20 11:23:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) Resent-From: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Jul 2025 16:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79023 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Third Cc: Eli Zaretskii , 79023@debbugs.gnu.org Received: via spool by 79023-submit@debbugs.gnu.org id=B79023.17526843611408 (code B ref 79023); Wed, 16 Jul 2025 16:46:02 +0000 Received: (at 79023) by debbugs.gnu.org; 16 Jul 2025 16:46:01 +0000 Received: from localhost ([127.0.0.1]:50399 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uc5Gb-0000Me-28 for submit@debbugs.gnu.org; Wed, 16 Jul 2025 12:46:01 -0400 Received: from fhigh-b2-smtp.messagingengine.com ([202.12.124.153]:59649) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uc5GY-0000ML-6U for 79023@debbugs.gnu.org; Wed, 16 Jul 2025 12:45:59 -0400 Received: from phl-compute-04.internal (phl-compute-04.phl.internal [10.202.2.44]) by mailfhigh.stl.internal (Postfix) with ESMTP id BD2FA7A00D8; Wed, 16 Jul 2025 12:45:51 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Wed, 16 Jul 2025 12:45:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaminski.se; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1752684351; x=1752770751; bh=qcvH4ELTtox9l/yIEDV9BtPFH6Oqoski3gFVQxkjcZA=; b= rE7p9AWYxTUTOLt+ec7vWhLB+Liw/w5K9+9+W6LXRWuYytObcxYa67OyuCzeS9In LxioSIis7zsHDQYSqyKWBLZa6IcKqNh1pP3zqlT1EmX0IA3fMb6xoTFTZym6tbDG tjP7+Aygnvd0UtdovTzD16KUF6/lh0Nw3tX0bvTgEWIbdQLWEviDdnQNfusm/6mK XdbUkZmpnuewkGY7Ewo5shRws3UhzlDehqoybhS5IQziCGFaCowK/TAqev+AK1AU dCIlYBNtQFkokm1GfXT2Ed4w/TWJ72fn07nZdzgINT4vRV/UECYjpO+/mjo0DYQ0 WC1zv6pC1tV29yHbfPs7Cg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1752684351; x= 1752770751; bh=qcvH4ELTtox9l/yIEDV9BtPFH6Oqoski3gFVQxkjcZA=; b=F dsIvINFdEnys9crpbqOVrWUY8tHXtSIc2OKIjs612yRBCnAkgxF7Iawc8mpE493d 3HA6bX2/iqVcG7kNlwE1vEjleeVCFK6mMDg77TTelCNioNgb/utaGAJmsSsk3ygr fzdcytfAq1M7dt/hq954vWv/nZVgmAevosET9ngZyJfv3KLt9bjwR2XMNvoMIjzZ LYZ47+u26932oMw4Np9/fXLi1EJl+MDbSTY6dfCcafDY1CyvHkoMdbAt1Yorzv9h 7vh9xFieuOmrxaYIK/4n5lqJfhii2+DWA8mGHzcFonLoO/lolODFAe5hgLj/VcSg b2R3SvY4JS9SaMmYE2dbA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdehkedvfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffoffkjghfgggtgfesrgekmherredtjeenucfhrhhomheprfhriigvmhih shhlrgifucetlhgvgigrnhguvghrucfmrghmihnkshhkihcuoehprhiivghmhihslhgrfi eskhgrmhhinhhskhhirdhsvgeqnecuggftrfgrthhtvghrnheptddvteevheevheeihefg tdfhjedtvedtveduudfhgfejgeelvdfhvdfhffehheffnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepphhriigvmhihshhlrgifsehkrghmihhn shhkihdrshgvpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpohhuthdprhgtph htthhopegrlhgrnhesihguihhotgihrdhorhhgpdhrtghpthhtohepvghlihiisehgnhhu rdhorhhgpdhrtghpthhtohepjeeltddvfeesuggvsggsuhhgshdrghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i08494404:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 16 Jul 2025 12:45:50 -0400 (EDT) From: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Date: Wed, 16 Jul 2025 18:45:47 +0200 X-Mailer: MailMate (1.14r5937) Message-ID: <12B18FD9-76BB-4B4C-A364-BFDE29635387@kaminski.se> In-Reply-To: References: <5BA8A8B9-96CB-4823-836B-49CEBED77CEF@kaminski.se> <86ldopk5hq.fsf@gnu.org> <113CE362-63BF-4F13-845C-1DB8F6D8580C@kaminski.se> <86frexk2ds.fsf@gnu.org> <0B829A49-5464-40AE-B860-3BEC183A3F4B@kaminski.se> <865xfsjsv6.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_670B3601-6AD1-4824-84BB-B4457F3496DF_=" Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=_MailMate_670B3601-6AD1-4824-84BB-B4457F3496DF_= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Update to the topic: - I've setup up debug pipeline and was able to make a proper clean build and ensured GC plenty had plenty time to grab (snapshots every 30s) - Only minor leaks are remaining - I started looking at the allocations: on clean instance moving mouse/resizing window was expensive (see excerpt) - Instance with uptime of 1 hour it has footprint of 405MiB (mind the debugging symbols though) Best, Przemysław Alexander Kamiński --- 20.06 MB 99.0% 6421 start 20.06 MB 99.0% 6421 main 20.06 MB 99.0% 6421 Frecursive_edit 20.06 MB 99.0% 6421 recursive_edit_1 20.06 MB 99.0% 6421 command_loop 20.06 MB 99.0% 6421 command_loop.cold.1 20.06 MB 99.0% 6421 internal_catch 20.06 MB 99.0% 6421 command_loop_2 20.06 MB 99.0% 6421 internal_condition_case 20.06 MB 99.0% 6421 command_loop_1 20.04 MB 98.9% 6274 read_key_sequence 20.04 MB 98.9% 6273 read_char 19.24 MB 94.9% 588 read_decoded_event_from_main_queue 19.24 MB 94.9% 588 read_event_from_main_queue 19.24 MB 94.9% 587 kbd_buffer_get_event 19.24 MB 94.9% 587 wait_reading_process_output 11.11 MB 54.8% 584 ns_select_1 11.11 MB 54.8% 584 -[EmacsApp run] 11.11 MB 54.8% 584 -[NSApplication run] 11.09 MB 54.7% 558 -[NSApplication _handleEvent:] 11.09 MB 54.7% 558 -[EmacsApp sendEvent:] 11.09 MB 54.7% 558 -[NSApplication(NSEventRouting) sendEvent:] 11.09 MB 54.7% 558 -[NSWindow(NSEventRouting) sendEvent:] 11.09 MB 54.7% 558 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] 11.09 MB 54.7% 558 -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] 11.09 MB 54.7% 558 -[NSThemeFrame mouseDown:] 11.09 MB 54.7% 558 -[NSThemeFrame handleMouseDown:] 11.09 MB 54.7% 558 -[NSTitledFrame attemptResizeWithEvent:] 11.09 MB 54.7% 558 -[NSWindow(NSWindowResizing) _resizeWithEvent:] 11.07 MB 54.6% 416 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] 7.66 KB 0.0% 88 -[NSWindow(NSWindowResizing) _frame:resizedFromEdge:withDelta:withEvent:withState:] 7.34 KB 0.0% 29 -[EmacsWindow setFrame:display:] 3.27 KB 0.0% 21 -[NSWindow _endLiveResize] 384 Bytes 0.0% 2 -[NSAutoreleasePool drain] 96 Bytes 0.0% 1 -[NSWindow(NSScreenLayout) _saveWindowLayoutForScreenLayout] 64 Bytes 0.0% 1 _objc_msgSend_uncached 19.36 KB 0.0% 26 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] 8.13 MB 40.0% 3 detect_input_pending_run_timers 8.13 MB 40.0% 3 flush_frame 8.13 MB 40.0% 3 ns_flush_display 8.13 MB 40.0% 3 ns_read_socket_1 8.13 MB 40.0% 3 -[EmacsApp run] 8.13 MB 40.0% 3 -[NSApplication run] 8.13 MB 40.0% 3 -[NSApplication _handleEvent:] 8.13 MB 40.0% 3 -[EmacsApp sendEvent:] 8.13 MB 40.0% 3 -[NSApplication(NSEventRouting) sendEvent:] 8.13 MB 40.0% 3 routeMouseMovedEvent 8.13 MB 40.0% 3 -[NSWindow(NSEventRouting) sendEvent:] 8.13 MB 40.0% 3 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] 8.13 MB 40.0% 3 _routeMouseMovedEvent 8.13 MB 40.0% 3 -[EmacsView mouseMoved:] 8.13 MB 40.0% 3 ns_note_mouse_movement 8.13 MB 40.0% 3 -[EmacsView lockFocus] 8.13 MB 40.0% 3 -[EmacsLayer getContext] 8.13 MB 40.0% 3 IOSurfaceCreate 8.13 MB 40.0% 2 -[IOSurface initWithProperties:] 8.13 MB 40.0% 2 IOSurfaceClientCreateChild 400 Bytes 0.0% 1 _ioSurfaceClientCreateWithLockResult 400 Bytes 0.0% 1 _malloc_type_malloc_outlined 16 Bytes 0.0% 1 _objc_rootAllocWithZone 16 Bytes 0.0% 1 _malloc_type_calloc_outlined --=_MailMate_670B3601-6AD1-4824-84BB-B4457F3496DF_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Update to the topic:

  • I've setup up debug pipeline and was able to make a proper clean buil= d and ensured GC plenty had plenty time to grab (snapshots every 30s)
  • Only minor leaks are remaining
  • I started looking at the allocations: on clean instance moving mouse/= resizing window was expensive (see excerpt)
  • Instance with uptime of 1 hour it has footprint of 405MiB (mind the d= ebugging symbols though)

Best,
Przemys=C5=82aw Alexander Kami=C5=84ski


20.06 MB 99.0% 6421 start
20.06 MB 99.0% 6421 main
20.06 MB 99.0% 6421 Frecursive_edit
20.06 MB 99.0% 6421 recursive_edit_1
20.06 MB 99.0% 6421 command_loop
20.06 MB 99.0% 6421 command_loop.cold.1
20.06 MB 99.0% 6421 internal_catch
20.06 MB 99.0% 6421 command_loop_2
20.06 MB 99.0% 6421 internal_condition_case
20.06 MB 99.0% 6421 command_loop_1
20.04 MB 98.9% 6274 read_key_sequence
20.04 MB 98.9% 6273 read_char
19.24 MB 94.9% 588 read_decoded_event_from_main_queue<= br> 19.24 MB 94.9% 588 read_event_from_main_queue
19.24 MB 94.9% 587 kbd_buffer_get_event
19.24 MB 94.9% 587 wait_reading_process_output
11.11 MB 54.8% 584 ns_select_1
11.11 MB 54.8% 584 -[EmacsApp run]
11.11 MB 54.8% 584 -[NSApplication run]
11.09 MB 54.7% 558 -[NSApplication _handleEvent= :]
11.09 MB 54.7% 558 -[EmacsApp sendEvent:]
11.09 MB 54.7% 558 -[NSApplication(NSEventRou= ting) sendEvent:]
11.09 MB 54.7% 558 -[NSWindow(NSEventRouting= ) sendEvent:]
11.09 MB 54.7% 558 -[NSWindow(NSEventRoutin= g) _reallySendEvent:isDelayedEvent:]
11.09 MB 54.7% 558 -[NSWindow(NSEventRouti= ng) _handleMouseDownEvent:isDelayedEvent:]
11.09 MB 54.7% 558 -[NSThemeFrame mouseDo= wn:]
11.09 MB 54.7% 558 -[NSThemeFrame handle= MouseDown:]
11.09 MB 54.7% 558 -[NSTitledFrame atte= mptResizeWithEvent:]
11.09 MB 54.7% 558 -[NSWindow(NSWindow= Resizing) _resizeWithEvent:]
11.07 MB 54.6% 416 -[NSApplication(NS= EventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
7.66 KB 0.0% 88 -[NSWindow(NSWindowR= esizing) _frame:resizedFromEdge:withDelta:withEvent:withState:]
7.34 KB 0.0% 29 -[EmacsWindow setFra= me:display:]
3.27 KB 0.0% 21 -[NSWindow _endLiveR= esize]
384 Bytes 0.0% 2 -[NSAutoreleasePool dr= ain]
96 Bytes 0.0% 1 -[NSWindow(NSScreenLayo= ut) _saveWindowLayoutForScreenLayout]
64 Bytes 0.0% 1 _objc_msgSend_uncached<= br> 19.36 KB 0.0% 26 -[NSApplication(NSEventRoutin= g) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
8.13 MB 40.0% 3 detect_input_pending_run_timers 8.13 MB 40.0% 3 flush_frame
8.13 MB 40.0% 3 ns_flush_display
8.13 MB 40.0% 3 ns_read_socket_1
8.13 MB 40.0% 3 -[EmacsApp run]
8.13 MB 40.0% 3 -[NSApplication run]
8.13 MB 40.0% 3 -[NSApplication _handleEvent= :]
8.13 MB 40.0% 3 -[EmacsApp sendEvent:]
8.13 MB 40.0% 3 -[NSApplication(NSEventRou= ting) sendEvent:]
8.13 MB 40.0% 3 routeMouseMovedEvent
8.13 MB 40.0% 3 -[NSWindow(NSEventRoutin= g) sendEvent:]
8.13 MB 40.0% 3 -[NSWindow(NSEventRouti= ng) _reallySendEvent:isDelayedEvent:]
8.13 MB 40.0% 3 _routeMouseMovedEvent<= br> 8.13 MB 40.0% 3 -[EmacsView mouseMove= d:]
8.13 MB 40.0% 3 ns_note_mouse_moveme= nt
8.13 MB 40.0% 3 -[EmacsView lockFoc= us]
8.13 MB 40.0% 3 -[EmacsLayer getCo= ntext]
8.13 MB 40.0% 3 IOSurfaceCreate 8.13 MB 40.0% 2 -[IOSurface init= WithProperties:]
8.13 MB 40.0% 2 IOSurfaceClient= CreateChild
400 Bytes 0.0% 1 _ioSurfaceClien= tCreateWithLockResult
400 Bytes 0.0% 1 _malloc_type_m= alloc_outlined
16 Bytes 0.0% 1 _objc_rootAllocWit= hZone
16 Bytes 0.0% 1 _malloc_type_call= oc_outlined

--=_MailMate_670B3601-6AD1-4824-84BB-B4457F3496DF_=-- From unknown Sun Jul 20 11:23:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) Resent-From: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Jul 2025 13:36:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79023 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Third Cc: Eli Zaretskii , 79023@debbugs.gnu.org Received: via spool by 79023-submit@debbugs.gnu.org id=B79023.175275931126345 (code B ref 79023); Thu, 17 Jul 2025 13:36:04 +0000 Received: (at 79023) by debbugs.gnu.org; 17 Jul 2025 13:35:11 +0000 Received: from localhost ([127.0.0.1]:53640 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ucOlQ-0006pj-4t for submit@debbugs.gnu.org; Thu, 17 Jul 2025 09:35:10 -0400 Received: from fout-b2-smtp.messagingengine.com ([202.12.124.145]:42821) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ucOlJ-0006mj-G8 for 79023@debbugs.gnu.org; Thu, 17 Jul 2025 09:35:05 -0400 Received: from phl-compute-03.internal (phl-compute-03.phl.internal [10.202.2.43]) by mailfout.stl.internal (Postfix) with ESMTP id 9F3291D001B6; Thu, 17 Jul 2025 09:34:55 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-03.internal (MEProxy); Thu, 17 Jul 2025 09:34:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaminski.se; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1752759295; x=1752845695; bh=AwMep7iJH5iESzIaFYQk4jcutV9w9CgTx2kTxasAN+k=; b= oXm1y/lpMg7nFSALEFyVcaZyFI+YmEAa2NqpSP1KdsBTGpxyW1gKjVtSUMDhIUDx tWqyT858fY/jI33NDHOLEUlSeRxx6PIoyMiWf+HCZ0qs0TpzRwyZsoNgTSMOe5aX M390bxL5AYTToA3yB4flDRVSye9QV0c5sV1KcX6bMKPkAZcESBsprIAak5Xj3HrU rK+o1QVU2UTkmfBn3jwvCTcI82bSUP1SVfUWqjXX2GRyJTXxhpSF7EIW0HjlllyT wXg4+lc42cXcVvu8kr4z96Fc/fVDOs3VNpvkmBTEIWGjhP5AzZcKeBiaVpEb4hLe GPNooTA+1NZaM7bGIdEuoQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1752759295; x= 1752845695; bh=AwMep7iJH5iESzIaFYQk4jcutV9w9CgTx2kTxasAN+k=; b=L OwZq311K8mCu/6Oz02OeaAgWk4vA6qh2be9NncfhbhsPePBflWzxU7x9NP6kZsFS kTFAMFaOY6ZPx1VsYdY1Iy3cvw1Qhs5u8IHwS88F+bI1VjJhXRV6zmxSmLdl9UFp tYsEMnE6/YidfUyJAI8gZeKZ+Jkz4WUTwG378Jsd8yf+SQrNcEekKCWmaJpYG1e1 JAtXglwpdf/aOk32ZFLGabEhSeGat/1sx7P18Rs9qoflT0g2/YfpE3WSh2fm9CVM lVSKpbMZ2CN0qRaXptzDMRzppiej4BL1jv/+aRUlKg9YSxsbGdujawD0RbvlMg5Z H+pxVCG8BHFwBkiUFX/QA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdeitdejvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffoffkjghfgggtgfesrgekmherredtjeenucfhrhhomheprfhriigvmhih shhlrgifucetlhgvgigrnhguvghrucfmrghmihnkshhkihcuoehprhiivghmhihslhgrfi eskhgrmhhinhhskhhirdhsvgeqnecuggftrfgrthhtvghrnheptddvteevheevheeihefg tdfhjedtvedtveduudfhgfejgeelvdfhvdfhffehheffnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepphhriigvmhihshhlrgifsehkrghmihhn shhkihdrshgvpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpohhuthdprhgtph htthhopegrlhgrnhesihguihhotgihrdhorhhgpdhrtghpthhtohepvghlihiisehgnhhu rdhorhhgpdhrtghpthhtohepjeeltddvfeesuggvsggsuhhgshdrghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i08494404:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 17 Jul 2025 09:34:54 -0400 (EDT) From: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Date: Thu, 17 Jul 2025 15:34:51 +0200 X-Mailer: MailMate (1.14r5937) Message-ID: <09CCE7F5-1D91-46E2-ADA8-6F76C2AC6D61@kaminski.se> In-Reply-To: <12B18FD9-76BB-4B4C-A364-BFDE29635387@kaminski.se> References: <5BA8A8B9-96CB-4823-836B-49CEBED77CEF@kaminski.se> <86ldopk5hq.fsf@gnu.org> <113CE362-63BF-4F13-845C-1DB8F6D8580C@kaminski.se> <86frexk2ds.fsf@gnu.org> <0B829A49-5464-40AE-B860-3BEC183A3F4B@kaminski.se> <865xfsjsv6.fsf@gnu.org> <12B18FD9-76BB-4B4C-A364-BFDE29635387@kaminski.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_2B0AECC3-BD05-4375-A5BB-07A0E3198D5D_=" Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=_MailMate_2B0AECC3-BD05-4375-A5BB-07A0E3198D5D_= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I'm confident I've been able to found the root cause, no fix yet. It's easy to reproduce: start new instance, grab resize handle and resize away. I'm looking right now at a trace 23.3 seconds long trace. It has: - "redisplay" 644 420 times allocating (but not leaking) - total transient allocation vokume is 1.6 GB - when removing windowWillResize/setFrame/layoutSublayersOfLayer there are only 1765 extra allocations I think that overall slowness comes from that and fragmentation that comes with it. After some time I can imagine it's difficult to grab a 2KiB slot from OS. The outliers seems to be drawing glyphs, but I wouldn't focus on it first. IMO there are two root causes: - Major one: processing all the events without filtering (I have 5397 attemptResizeWithEvent events handled in 10 seconds - I'm sure I didn't resize windows for that long) - Minor one: inefficient redrawing, but given number of allocations I think that autorelease pool might handle it (once it stops processing 100MiB/second event streams ;-)) I'll try do deliver some prototype, but I'm not sure if that'd be anything integration-worthy. Best, Przemysław Alexander Kamiński --- Most allocation-heavy stacktrace tail (count is total allocations in the inspected, 10s long frame): 2 172166 ns_draw_glyph_string_foreground [inlined] emacs emacs/src/nsterm.m:4278 1 172166 macfont_draw emacs emacs/src/macfont.m:2951 Transient allocations trace excerpt: 1878.09 MB 100.0% 1613815 emacs -[EmacsApp run] 1874.40 MB 99.8% 1576278 emacs -[EmacsApp sendEvent:] 1653.78 MB 88.0% 644420 emacs -[EmacsView layoutSublayersOfLayer:] 24.48 MB 1.3% 184083 emacs -[EmacsWindow setFrame:display:] 44.38 MB 2.3% 143554 emacs -[EmacsView windowWillResize:toSize:] 200.22 KB 0.0% 2237 emacs -[EmacsView mouseMoved:] 17.88 KB 0.0% 520 emacs -[EmacsWindow constrainFrameRect:toScreen:] 7.72 KB 0.0% 494 emacs -[EmacsLayer display] 25.00 KB 0.0% 480 emacs -[EmacsApp stop:] 77.17 KB 0.0% 177 emacs -[EmacsView viewDidEndLiveResize] 14.62 KB 0.0% 78 emacs ns_send_appdefined 20.58 KB 0.0% 68 emacs -[EmacsView windowDidResignKey:] 14.09 KB 0.0% 213 emacs -[EmacsLayer display] 5.73 KB 0.0% 65 emacs -[EmacsWindow accessibilityAttributeValue:] 192 Bytes 0.0% 1 emacs ns_send_appdefined --=_MailMate_2B0AECC3-BD05-4375-A5BB-07A0E3198D5D_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'm confident I've been able to found the root cause, no = fix yet.

It's easy to reproduce: start new instance, grab resize h= andle and resize away.

I'm looking right now at a trace 23.3 seconds long trace.= It has:

  • "redisplay" 644 420 times allocating (but not leaking)
  • =
  • total transient allocation vokume is 1.6 GB
  • when removing windowWillResize/setFrame/layoutSublayersOfLayer there = are only 1765 extra allocations

I think that overall slowness comes from that and fragmen= tation that comes with it. After some time I can imagine it's difficult t= o grab a 2KiB slot from OS.

The outliers seems to be drawing glyphs, but I wouldn't f= ocus on it first.

IMO there are two root causes:

  • Major one: processing all the events without filtering (I have 5397 a= ttemptResizeWithEvent events handled in 10 seconds - I'm sure I didn't re= size windows for that long)
  • Minor one: inefficient redrawing, but given number of allocations I = think that autorelease pool might handle it (once it stops processing 100= MiB/second event streams ;-))

I'll try do deliver some prototype, but I'm not sure if t= hat'd be anything integration-worthy.

Best,
Przemys=C5=82aw Alexander Kami=C5=84ski


Most allocation-heavy stacktrace tail (count is total all= ocations in the inspected, 10s long frame):

2 172166 ns_draw_glyph_string_foreground [inlined] emacs= emacs/src/nsterm.m:4278
1 172166 macfont_draw emacs emacs/src/macfont.m:2951

Transient allocations trace excerpt:

1878.09 MB 100.0% 1613815 emacs -[EmacsApp run]
= 1874.40 MB 99.8% 1576278 emacs -[EmacsApp sendEvent:]
1653.78 MB 88.0% 644420 emacs -[EmacsView layoutSublayersOfLayer= :]
24.48 MB 1.3% 184083 emacs -[EmacsWindow setFrame:display:]
= 44.38 MB 2.3% 143554 emacs -[EmacsView windowWillResize:toSize:= ]
200.22 KB 0.0% 2237 emacs -[EmacsView mouseMoved:]
17.88 KB 0.0% 520 emacs -[EmacsWindow constrainFrameRect:toScre= en:]
7.72 KB 0.0% 494 emacs -[EmacsLayer display]
25.00 KB 0.0% 480 emacs -[EmacsApp stop:]
77.17 KB 0.0% 177 emacs -[EmacsView viewDidEndLiveResize]
14.62 KB 0.0% 78 emacs ns_send_appdefined
20.58 KB 0.0% 68 emacs -[EmacsView windowDidResignKey:]
14.09 KB 0.0% 213 emacs -[EmacsLayer display]
5.73 KB 0.0% 65 emacs -[EmacsWindow accessibilityAttributeValue:= ]
192 Bytes 0.0% 1 emacs ns_send_appdefined

--=_MailMate_2B0AECC3-BD05-4375-A5BB-07A0E3198D5D_=-- From unknown Sun Jul 20 11:23:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Jul 2025 14:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79023 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Cc: Eli Zaretskii , 79023@debbugs.gnu.org Received: via spool by 79023-submit@debbugs.gnu.org id=B79023.175276305512494 (code B ref 79023); Thu, 17 Jul 2025 14:38:02 +0000 Received: (at 79023) by debbugs.gnu.org; 17 Jul 2025 14:37:35 +0000 Received: from localhost ([127.0.0.1]:55157 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ucPjq-0003FO-QF for submit@debbugs.gnu.org; Thu, 17 Jul 2025 10:37:35 -0400 Received: from dane.soverin.net ([2a10:de80:1:4092:b9e9:229d:0:1]:57843) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1ucPjn-0003Ea-3Q for 79023@debbugs.gnu.org; Thu, 17 Jul 2025 10:37:31 -0400 Received: from smtp.soverin.net (c04smtp-lb01.int.sover.in [10.10.4.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4bjb9Z6SwlzybW; Thu, 17 Jul 2025 14:37:22 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net (Postfix) with ESMTPSA id 4bjb9Z3MHBz43; Thu, 17 Jul 2025 14:37:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1752763042; bh=x6uCKDY8DI4v1NnLgLhZl97qT6rwqqB1gZEFVEexrdQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JoziyI7P+rG4Y6YcdUEgMchM+5TTfygGB5N2u1vcjM/PkYN1S3z3vv4gKFbFPFRG3 9A6+hk7yXYFfzY6lmxXzhQMjrd8fHViDvaUOzvUKmF9gm1i6+G8NmorAYIdsgXQXYj vfe1BZQQFKElhYKJxKMMg9MeqvcE7hF+qxCEvtrLpSEuPOegWmZ0FRXOLJMYS9ijsF UuTCBmi29eQjmyHTBR8NaTK2HPnk3rmA0mfOwXFAoL8W/nynWuNeQUw3XxCSN66Q3m Tu2MePAUDCdjnSVgmdFoN+XvcQ3PiE4Iadi/vEJTTt70iFfByV8OhpZT7VdDXW2QGo JmkhorxUCAWzw== X-CM-Analysis: v=2.4 cv=d/oPyQjE c=1 sm=1 tr=0 ts=68790aa2 a=IkcTkHD0fZMA:10 a=Wb1JkmetP80A:10 a=mIxs_Ld5p52SRfD1G5QA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=zY0JdQc1-4EAyPf5TuXT:22 Received: from localhost (faroe.holly.idiocy.org [local]) by faroe.holly.idiocy.org (OpenSMTPD) with ESMTPA id c4ee3e7f; Thu, 17 Jul 2025 14:37:21 +0000 (UTC) Date: Thu, 17 Jul 2025 15:37:21 +0100 From: Alan Third Message-ID: Mail-Followup-To: Alan Third , =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= , Eli Zaretskii , 79023@debbugs.gnu.org References: <86ldopk5hq.fsf@gnu.org> <113CE362-63BF-4F13-845C-1DB8F6D8580C@kaminski.se> <86frexk2ds.fsf@gnu.org> <0B829A49-5464-40AE-B860-3BEC183A3F4B@kaminski.se> <865xfsjsv6.fsf@gnu.org> <12B18FD9-76BB-4B4C-A364-BFDE29635387@kaminski.se> <09CCE7F5-1D91-46E2-ADA8-6F76C2AC6D61@kaminski.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <09CCE7F5-1D91-46E2-ADA8-6F76C2AC6D61@kaminski.se> X-Spampanel-Class: ham X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On Thu, Jul 17, 2025 at 03:34:51PM +0200, Przemysław Alexander Kamiński wrote: > I'm confident I've been able to found the root cause, no fix yet. > > It's easy to reproduce: start new instance, grab resize handle and resize > away. It could be worth looking into whether we're releasing IOSurface's correctly. I've had a look and the code looks OK to me, but I'm not an expert on their use. Basically, every time the system decides to display a new window size it will release all the IOSurfaces and generate at least one new one at the new size. We then call redisplay to fill in that new buffer. Obviously in the midst of a resize that's going to result in quite a lot of work, and the IOSurface buffers can be quite big, which is why I thought of them first. -- Alan Third From unknown Sun Jul 20 11:23:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) Resent-From: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Jul 2025 15:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79023 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Third Cc: Eli Zaretskii , 79023@debbugs.gnu.org Received: via spool by 79023-submit@debbugs.gnu.org id=B79023.175276454519192 (code B ref 79023); Thu, 17 Jul 2025 15:03:01 +0000 Received: (at 79023) by debbugs.gnu.org; 17 Jul 2025 15:02:25 +0000 Received: from localhost ([127.0.0.1]:55339 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ucQ7t-0004zP-6Q for submit@debbugs.gnu.org; Thu, 17 Jul 2025 11:02:25 -0400 Received: from fout-b3-smtp.messagingengine.com ([202.12.124.146]:56367) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ucQ7q-0004yf-03 for 79023@debbugs.gnu.org; Thu, 17 Jul 2025 11:02:22 -0400 Received: from phl-compute-09.internal (phl-compute-09.phl.internal [10.202.2.49]) by mailfout.stl.internal (Postfix) with ESMTP id CB33D1D00026; Thu, 17 Jul 2025 11:02:15 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-09.internal (MEProxy); Thu, 17 Jul 2025 11:02:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaminski.se; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1752764535; x=1752850935; bh=ZYKarYT4KWR1X95i2xW5RIRLBvPweiUmRdowJg23wp4=; b= cxrLRApsV2Gba4AH0ZJW0L20Zz6J8g97Filet2DDDUPh7r/z/daS7XH6HU5lDnVv Gw02WhRH8MKiIdpY9XYJcEhxqyAW/EdjPOmwpqaXICJPnpDPqAQaGvMJpqcLKKVB RB+V1Ay5sZJlVtw34nShV+UjbhMhRk2zdR/ob+HGi9P2bgLtwPa18FBeOeeWK7kD dErI7bpCn9qCb68INbgjxL6B+P6B13fiHlp/quzsUEr5lTvZ3x2cshrYvCrMl7Ca 3LxovS0MgiEG5E2WgtBHDcJ9GtgazYuUc0gXRa4m/r3OUIZmlVOy0xxVqwNCTX+L yeMkYd3xVkmIwss0AWUnXQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1752764535; x= 1752850935; bh=ZYKarYT4KWR1X95i2xW5RIRLBvPweiUmRdowJg23wp4=; b=i 7jlans5KMckWvZehtEB6nmHbfmTKnLv9EqRexhUpJ9PSwID6N+TCd0uWJ5t8IOZu g6y8pxZXZUSYcto4i021AcjHWQGk8upVgOIiQKd62sjnnMUBN/Zfgm1KIw7F2XZI +CCtXMQZoRqsM6CHYHhdAJvD/o7bNBVFf+5rfmS6uOrPUIriUESobiIvHY5c/g3v 4N9txfKWYwU2GW3intuwok8/pZWnJf++e9j2QptVxx9i4za8XjXocDeQyncJddBC Lei+hH3NLlCmGNruutCVHfZhDsqSqUC5dczzDJcTzFZyKEnMta2/htNSanvuOuMy wkTMfL8EwIurNZrUpmbwg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdeitdeklecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffoffkjghfgggtgfesrgekmherredtjeenucfhrhhomheprfhriigvmhih shhlrgifucetlhgvgigrnhguvghrucfmrghmihnkshhkihcuoehprhiivghmhihslhgrfi eskhgrmhhinhhskhhirdhsvgeqnecuggftrfgrthhtvghrnheptddvteevheevheeihefg tdfhjedtvedtveduudfhgfejgeelvdfhvdfhffehheffnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepphhriigvmhihshhlrgifsehkrghmihhn shhkihdrshgvpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpohhuthdprhgtph htthhopegrlhgrnhesihguihhotgihrdhorhhgpdhrtghpthhtohepvghlihiisehgnhhu rdhorhhgpdhrtghpthhtohepjeeltddvfeesuggvsggsuhhgshdrghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i08494404:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 17 Jul 2025 11:02:14 -0400 (EDT) From: =?UTF-8?Q?Przemys=C5=82aw?= Alexander =?UTF-8?Q?Kami=C5=84ski?= Date: Thu, 17 Jul 2025 17:02:11 +0200 X-Mailer: MailMate (1.14r5937) Message-ID: <08F33811-5319-4D63-A2D0-E7854D6C380C@kaminski.se> In-Reply-To: References: <86ldopk5hq.fsf@gnu.org> <113CE362-63BF-4F13-845C-1DB8F6D8580C@kaminski.se> <86frexk2ds.fsf@gnu.org> <0B829A49-5464-40AE-B860-3BEC183A3F4B@kaminski.se> <865xfsjsv6.fsf@gnu.org> <12B18FD9-76BB-4B4C-A364-BFDE29635387@kaminski.se> <09CCE7F5-1D91-46E2-ADA8-6F76C2AC6D61@kaminski.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_FC7EEC33-02E3-467B-A347-4FBE83498AD2_=" Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=_MailMate_FC7EEC33-02E3-467B-A347-4FBE83498AD2_= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 17 Jul 2025, at 16:37, Alan Third wrote: > On Thu, Jul 17, 2025 at 03:34:51PM +0200, Przemysław Alexander > Kamiński wrote: > It could be worth looking into whether we're releasing IOSurface's > correctly. I've had a look and the code looks OK to me, but I'm not an > expert on their use. It's definitelly fine. Objects are released and are hefty but there are only few allocations. I done the stupidest fix possible. I put 0.1 sleep in layoutSublayersOfLayer and then 0.05 sleep for windowWillResize. Resizing is not so smooth but: - Number of allocations dropped considerably - Instance, after furious resizing, sits at 263MiB instead of 1.6GiB I saw some allocations still going, so investigated and... tracing process. It looks like with slowed down redrawing it can reuse object pool without expanding it and keeping overal memory low. I ran this instance with my config and it properly shrinks memory usage while sitting at 500MiB of stable usage. On top of it - memory usage seems to get back to baseline after further resizing. I'm going to build it with all the libs/flags I use usually and run it for some time to see if there aren't any issues with it. Best, Przemysław Alexander Kamiński --=_MailMate_FC7EEC33-02E3-467B-A347-4FBE83498AD2_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 17 Jul 2025, at 16:37, Alan Third wrote:

On Thu, Jul 17, 2025 at 03:34:51PM = +0200, Przemys=C5=82aw Alexander Kami=C5=84ski wrote:
It could be worth looking into whether we're releasing IOSurface's
correctly. I've had a look and the code looks OK to me, but I'm not an
expert on their use.

It's definitelly fine. Objects are released and are hefty= but there are only few allocations.

I done the stupidest fix possible. I put 0.1 sleep in lay= outSublayersOfLayer and then 0.05 sleep for windowWillResize.

Resizing is not so smooth but:

  • Number of allocations dropped considerably
  • Instance, after furious resizing, sits at 263MiB instead of 1.6GiB

I saw some allocations still going, so investigated and..= =2E tracing process.
It looks like with slowed down redrawing it can reuse object pool without= expanding it and keeping overal memory low.

I ran this instance with my config and it properly shrink= s memory usage while sitting at 500MiB of stable usage. On top of it - me= mory usage seems to get back to baseline after further resizing. I'm goin= g to build it with all the libs/flags I use usually and run it for some t= ime to see if there aren't any issues with it.

Best,
Przemys=C5=82aw Alexander Kami=C5=84ski

--=_MailMate_FC7EEC33-02E3-467B-A347-4FBE83498AD2_=--