From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 15 03:13:35 2025 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?b?UHJ6ZW15c8WCYXcgQWxleGFuZGVyIEthbWnFhHNraQ==?= To: bug-gnu-emacs@gnu.org Subject: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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-Debbugs-Envelope-To: submit 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 debbugs-submit-bounces@debbugs.gnu.org Tue Jul 15 08:23:27 2025 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 To: =?utf-8?Q?Przemys=C5=82aw?= Alexander =?utf-8?Q?Kami=C5=84ski?= In-Reply-To: <5BA8A8B9-96CB-4823-836B-49CEBED77CEF@kaminski.se> (przemyslaw@kaminski.se) Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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-Debbugs-Envelope-To: 79023 Cc: 79023@debbugs.gnu.org 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 debbugs-submit-bounces@debbugs.gnu.org Tue Jul 15 09:02:13 2025 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?b?UHJ6ZW15c8WCYXcgQWxleGFuZGVyIEthbWnFhHNraQ==?= To: Eli Zaretskii Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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-Debbugs-Envelope-To: 79023 Cc: 79023@debbugs.gnu.org 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 debbugs-submit-bounces@debbugs.gnu.org Tue Jul 15 09:30:44 2025 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 To: =?utf-8?Q?Przemys=C5=82aw?= Alexander =?utf-8?Q?Kami=C5=84ski?= In-Reply-To: <113CE362-63BF-4F13-845C-1DB8F6D8580C@kaminski.se> (przemyslaw@kaminski.se) Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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-Debbugs-Envelope-To: 79023 Cc: 79023@debbugs.gnu.org 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 debbugs-submit-bounces@debbugs.gnu.org Tue Jul 15 09:52:39 2025 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?b?UHJ6ZW15c8WCYXcgQWxleGFuZGVyIEthbWnFhHNraQ==?= To: Eli Zaretskii Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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-Debbugs-Envelope-To: 79023 Cc: 79023@debbugs.gnu.org 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 debbugs-submit-bounces@debbugs.gnu.org Wed Jul 16 02:50:01 2025 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?b?UHJ6ZW15c8WCYXcgQWxleGFuZGVyIEthbWnFhHNraQ==?= To: Eli Zaretskii Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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-Debbugs-Envelope-To: 79023 Cc: 79023@debbugs.gnu.org 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 debbugs-submit-bounces@debbugs.gnu.org Wed Jul 16 07:09:03 2025 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 To: =?utf-8?Q?Przemys=C5=82aw?= Alexander =?utf-8?Q?Kami=C5=84ski?= In-Reply-To: <0B829A49-5464-40AE-B860-3BEC183A3F4B@kaminski.se> (przemyslaw@kaminski.se) Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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-Debbugs-Envelope-To: 79023 Cc: 79023@debbugs.gnu.org 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 debbugs-submit-bounces@debbugs.gnu.org Wed Jul 16 08:03:23 2025 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 To: =?utf-8?Q?Przemys=C5=82aw?= Alexander =?utf-8?Q?Kami=C5=84ski?= In-Reply-To: <74E43489-79B4-4980-8236-0CBFC48E61DD@kaminski.se> (przemyslaw@kaminski.se) Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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-Debbugs-Envelope-To: 79023 Cc: 79023@debbugs.gnu.org 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 debbugs-submit-bounces@debbugs.gnu.org Wed Jul 16 08:36:05 2025 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?b?UHJ6ZW15c8WCYXcgQWxleGFuZGVyIEthbWnFhHNraQ==?= To: Eli Zaretskii Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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-Debbugs-Envelope-To: 79023 Cc: 79023@debbugs.gnu.org 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 debbugs-submit-bounces@debbugs.gnu.org Wed Jul 16 08:54:20 2025 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?b?UHJ6ZW15c8WCYXcgQWxleGFuZGVyIEthbWnFhHNraQ==?= To: Eli Zaretskii Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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-Debbugs-Envelope-To: 79023 Cc: 79023@debbugs.gnu.org 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 think I can reproduce test case and even thin= k what might be the cause, as I looked around MacOS code for couple of mi= nutes.

Please do, and thanks.

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 debbugs-submit-bounces@debbugs.gnu.org Wed Jul 16 09:25:17 2025 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 To: =?utf-8?Q?Przemys=C5=82aw?= Alexander =?utf-8?Q?Kami=C5=84ski?= , Alan Third In-Reply-To: <1EDEC015-2F05-42CB-A5BA-C2FA6439859B@kaminski.se> (przemyslaw@kaminski.se) Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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-Debbugs-Envelope-To: 79023 Cc: 79023@debbugs.gnu.org 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 debbugs-submit-bounces@debbugs.gnu.org Wed Jul 16 10:16:11 2025 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?b?UHJ6ZW15c8WCYXcgQWxleGFuZGVyIEthbWnFhHNraQ==?= To: Eli Zaretskii Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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-Debbugs-Envelope-To: 79023 Cc: Alan Third , 79023@debbugs.gnu.org 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 debbugs-submit-bounces@debbugs.gnu.org Wed Jul 16 10:45:38 2025 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 To: =?utf-8?Q?Przemys=C5=82aw_Alexander_Kami=C5=84ski?= Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) Message-ID: Mail-Followup-To: Alan Third , =?utf-8?Q?Przemys=C5=82aw_Alexander_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-Debbugs-Envelope-To: 79023 Cc: Eli Zaretskii , 79023@debbugs.gnu.org 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 debbugs-submit-bounces@debbugs.gnu.org Wed Jul 16 10:51:37 2025 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?b?UHJ6ZW15c8WCYXcgQWxleGFuZGVyIEthbWnFhHNraQ==?= To: Alan Third Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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-Debbugs-Envelope-To: 79023 Cc: Eli Zaretskii , 79023@debbugs.gnu.org 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 debbugs-submit-bounces@debbugs.gnu.org Wed Jul 16 12:46:01 2025 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?b?UHJ6ZW15c8WCYXcgQWxleGFuZGVyIEthbWnFhHNraQ==?= To: Alan Third Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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-Debbugs-Envelope-To: 79023 Cc: Eli Zaretskii , 79023@debbugs.gnu.org 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 debbugs-submit-bounces@debbugs.gnu.org Thu Jul 17 09:35:10 2025 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?b?UHJ6ZW15c8WCYXcgQWxleGFuZGVyIEthbWnFhHNraQ==?= To: Alan Third Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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-Debbugs-Envelope-To: 79023 Cc: Eli Zaretskii , 79023@debbugs.gnu.org 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 debbugs-submit-bounces@debbugs.gnu.org Thu Jul 17 10:37:35 2025 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 To: =?utf-8?Q?Przemys=C5=82aw_Alexander_Kami=C5=84ski?= Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) Message-ID: Mail-Followup-To: Alan Third , =?utf-8?Q?Przemys=C5=82aw_Alexander_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-Debbugs-Envelope-To: 79023 Cc: Eli Zaretskii , 79023@debbugs.gnu.org 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 debbugs-submit-bounces@debbugs.gnu.org Thu Jul 17 11:02:25 2025 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?b?UHJ6ZW15c8WCYXcgQWxleGFuZGVyIEthbWnFhHNraQ==?= To: Alan Third Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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-Debbugs-Envelope-To: 79023 Cc: Eli Zaretskii , 79023@debbugs.gnu.org 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_=-- From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 21 15:16:46 2025 Received: (at 79023) by debbugs.gnu.org; 21 Jul 2025 19:16:46 +0000 Received: from localhost ([127.0.0.1]:59319 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1udw0D-0002Rt-Om for submit@debbugs.gnu.org; Mon, 21 Jul 2025 15:16:46 -0400 Received: from fhigh-a7-smtp.messagingengine.com ([103.168.172.158]:51023) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1udw0A-0002Re-T8 for 79023@debbugs.gnu.org; Mon, 21 Jul 2025 15:16:43 -0400 Received: from phl-compute-01.internal (phl-compute-01.phl.internal [10.202.2.41]) by mailfhigh.phl.internal (Postfix) with ESMTP id 38C2F140017B; Mon, 21 Jul 2025 15:16:37 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Mon, 21 Jul 2025 15:16:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adamkovic.org; 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=fm1; t=1753125397; x=1753211797; bh=tUAsDA/ggk+Mt3/82A/JbljPfSQU4yVQ HRR3fdUpg+w=; b=dqjNWL8KMD47euW9sA/hiFEQfaGmy6AxLnuCeMqa/UKpdOXy BKJTjNe+7SzFPI5hE9tb2PRQPH2cg3cVZW1mu6PTKDpQyVnTbmIgPLO2Bl4E+dtt 9hw7bTpSqlG3Hb+Oojkl7FTjVkwV6qv/QaJJqDaRXSBL3WHlsduKNd9JvHQoP//E DfKKSeSGZAm5jnMy/l0JtC1maLgi7RGS6sQQpqvjte/240/oVabju4DF8DIweu6u lWh05x5rNuxjKM9YPQaaMgJJ9XTFiYgg41JRb3WLWUvYE1dYBSKidaq6mZfKRYv/ 3DmaN4dUyM09NGq73mrObzIHqhobfuLqspbdsA== 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=1753125397; x= 1753211797; bh=tUAsDA/ggk+Mt3/82A/JbljPfSQU4yVQHRR3fdUpg+w=; b=F uIIvR5ZMGp4k5VBLr9Ll7GVbaGFrHxlGQ1uYCqxa09BFLwrg0HPmhckMAPVvJ/p3 t9qTYK75SfqGFp8owI55duECV3ivdU0Uh5NFHhCBUWa/ElW3Z4o3eNpMc6RYqFA5 d6lrQXDfOeO+68aMB4JfZZlBcNE7STUR+xV2E8rlbuaw6K0t6WHdg4lSBdaW11VE aB7qShhdNKb+PQ8wY+maQmKDT+xTFekshd6gVKoH75P2BmmJxY/GH84GQAR9DZ01 u/AQSmGlIdtTtgD+i3GdsjYsKlW5y0T5zeeLp7f9wWL8DX+yrIapsKbQsUjBVrg7 uBn8ROoOQTnvHKbDQp9Cw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdejvdeltdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufgjfhffkfggtgfgsehtqhertddttdejnecuhfhrohhmpeftuhguohhlfhcu tegurghmkhhovhhitgcuoehruhguohhlfhesrggurghmkhhovhhitgdrohhrgheqnecugg ftrfgrthhtvghrnhepieeuteehffdugffhgeegveehvedvtdekffelhfeuledugfetgfff ledthfdujeegnecuffhomhgrihhnpegruggrmhhkohhvihgtrdhorhhgnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhhuugholhhfsegruggr mhhkohhvihgtrdhorhhgpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpohhuth dprhgtphhtthhopeejledtvdefseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthht ohepphhriigvmhihshhlrgifsehkrghmihhnshhkihdrshgvpdhrtghpthhtohepvghlih iisehgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i88214938:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 21 Jul 2025 15:16:36 -0400 (EDT) From: Rudolf =?utf-8?Q?Adamkovi=C4=8D?= To: Eli Zaretskii , =?utf-8?Q?Przemys=C5=82aw?= Alexander =?utf-8?Q?Kami=C5=84ski?= Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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> Date: Mon, 21 Jul 2025 21:16:34 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79023 Cc: 79023@debbugs.gnu.org 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 (-) Eli Zaretskii writes: > Then let's hear from other macOS users: does anyone else who uses > Emacs on macOS have similar experience wrt the Emacs memory footprint? +1 I am on MacOS and my Emacs uses 2-4 GB RAM when in light use. P.S. Not sure if this is relevant but: Reproduction steps: 1. emacs -Q 2. evaluate in *scratch* the form: =20=20 (dotimes (x 1000) (let ((frame (make-frame-command))) (sleep-for 0.01) (delete-frame frame))) =20=20 Expected: Emacs uses ~60 MB of RAM (again), per the Activity Monitor. =20=20 Actual: Emacs uses 9.87 GB of RAM (10 minutes later, no change) Rudy --=20 "Programming reliably -- must be an activity of an undeniably mathematical nature [=E2=80=A6] You see, mathematics is about thinking, and doing mathematics is always trying to think as well as possible." --- Edsger W. Dijkstra, 1981 Rudolf Adamkovi=C4=8D [he/him] http://adamkovic.org From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 21 15:58:35 2025 Received: (at 79023) by debbugs.gnu.org; 21 Jul 2025 19:58:35 +0000 Received: from localhost ([127.0.0.1]:59454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1udweh-0005Fx-AV for submit@debbugs.gnu.org; Mon, 21 Jul 2025 15:58:35 -0400 Received: from fhigh-a7-smtp.messagingengine.com ([103.168.172.158]:49049) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1udwee-0005Fc-U0 for 79023@debbugs.gnu.org; Mon, 21 Jul 2025 15:58:33 -0400 Received: from phl-compute-01.internal (phl-compute-01.phl.internal [10.202.2.41]) by mailfhigh.phl.internal (Postfix) with ESMTP id 37B70140020C; Mon, 21 Jul 2025 15:58:27 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Mon, 21 Jul 2025 15:58:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adamkovic.org; 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=fm1; t=1753127907; x=1753214307; bh=78TuxE8n1uJ1EYbDbBKkquT1E1hmOocl C/3risab4eQ=; b=jHVZjp9/igO1iNTjR3Xv1tfjfhHZyb8PPZ/K67jPIBEZt7T7 9CvwEy33JhDIxyTHVE03yfZPs6artNTWJtA+2v0Rz9CjGinuR5d9+InPRyl8zspL n7vecsbHYP5kUDYDpTxHbZlkHsXnsPJrQ//C9cicISY/BL91vjPl0tIwvkzbHRFr 3ghKn4hB4U/5k5qV59tZOcOToTDlGlCAR8IJnly+mct10bD+LA6d/wymzpk1+oFA AfuXR5W6OgWdQELJX7qnd9hZc3brseOu5Yi7ffAq4xxdddOL6uwhcALR5DithLcQ v+eKA3E7CL1dEho27RE/ucBiws+bOOVC7q19cw== 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=1753127907; x= 1753214307; bh=78TuxE8n1uJ1EYbDbBKkquT1E1hmOoclC/3risab4eQ=; b=U 8m6vGcQEqOc1PCnMt6ZUcjL+/wkOIpnLZdHSF/OH8SWO997xL+AHzO3o9hAWfWXJ Y/UGqUJ+g/dCWXNqqoimZtkPk21q31S7kb/nX0AzrsanJdKitrOH59YX8MnoXSvo o2uhl/r5BHQvEhhVF/nuzQT4NQgYgbpmaKKfQKpzB//Lt+DK9Ll625ZkdRAZIVqy Engds7AnRj6YVa30wYSHI6bH/TEtXdJ6vIOIWr9UoAtZ/SLQmU1+Tu40l31x0kTG 8PNaEtpCGlSg1kEIfcmTYFOtj/uaCmVgY6mBoRSfGkiyjd0kFH/mPwUrAoR9phrG O23Ziz8hng52gldQHlEXw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdejvdeljecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufgjfhffkfggtgfgsehtqhertddttdejnecuhfhrohhmpeftuhguohhlfhcu tegurghmkhhovhhitgcuoehruhguohhlfhesrggurghmkhhovhhitgdrohhrgheqnecugg ftrfgrthhtvghrnhepieeuteehffdugffhgeegveehvedvtdekffelhfeuledugfetgfff ledthfdujeegnecuffhomhgrihhnpegruggrmhhkohhvihgtrdhorhhgnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhhuugholhhfsegruggr mhhkohhvihgtrdhorhhgpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpohhuth dprhgtphhtthhopeejledtvdefseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthht ohepphhriigvmhihshhlrgifsehkrghmihhnshhkihdrshgvpdhrtghpthhtohepvghlih iisehgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i88214938:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 21 Jul 2025 15:58:26 -0400 (EDT) From: Rudolf =?utf-8?Q?Adamkovi=C4=8D?= To: Eli Zaretskii , =?utf-8?Q?Przemys=C5=82aw?= Alexander =?utf-8?Q?Kami=C5=84ski?= Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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> Date: Mon, 21 Jul 2025 21:58:24 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79023 Cc: 79023@debbugs.gnu.org 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 (-) Rudolf Adamkovi=C4=8D writes: > (dotimes (x 1000) > (let ((frame (make-frame-command))) > (sleep-for 0.01) > (delete-frame frame))) Okay, while on it.... I did this for 100 frames with Instruments attached, after suffering through Apple signing nonsense. I found that Emacs leaks memory like there was no tomorrow (401 thousand leaks), but the leaks were too small to explain 5.22 GB of RAM used, per the Activity Monitor. So, I tried the Allocation instruments, in addition to Leaks, and indeed, and the code above resulted in 1098 allocations of 4.72 MB, totaling ~5.18 GB, and they are all like these: 1 0x4432b0000 VM: IOSurface 01:22.610.316 =E2=80=A2 4,72 MiB Emacs -[EmacsL= ayer getContext] 2 0x442df8000 VM: IOSurface 01:22.575.202 =E2=80=A2 4,72 MiB Emacs -[EmacsL= ayer getContext] 3 0x442940000 VM: IOSurface 01:22.509.260 =E2=80=A2 4,72 MiB Emacs -[EmacsL= ayer getContext] 4 0x442488000 VM: IOSurface 01:22.471.821 =E2=80=A2 4,72 MiB Emacs -[EmacsL= ayer getContext] 5 0x441fd0000 VM: IOSurface 01:22.422.630 =E2=80=A2 4,72 MiB Emacs -[EmacsL= ayer getContext] There are other allocations, of course, but these explain most of the memory pressure. The memory stays allocated even after waiting for 15 minutes, doing nothing. Rudy --=20 "The introduction of suitable abstractions is our only mental aid to organize and master complexity." --- Edsger Wybe Dijkstra, 1930-2002 Rudolf Adamkovi=C4=8D [he/him] http://adamkovic.org From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 21 19:33:57 2025 Received: (at 79023) by debbugs.gnu.org; 21 Jul 2025 23:33:57 +0000 Received: from localhost ([127.0.0.1]:60233 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ue016-0005va-MZ for submit@debbugs.gnu.org; Mon, 21 Jul 2025 19:33:57 -0400 Received: from fout-a1-smtp.messagingengine.com ([103.168.172.144]:52517) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ue014-0005vE-9g for 79023@debbugs.gnu.org; Mon, 21 Jul 2025 19:33:54 -0400 Received: from phl-compute-04.internal (phl-compute-04.phl.internal [10.202.2.44]) by mailfout.phl.internal (Postfix) with ESMTP id DAC6CEC005A; Mon, 21 Jul 2025 19:33:48 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Mon, 21 Jul 2025 19:33:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adamkovic.org; 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=fm1; t=1753140828; x= 1753227228; bh=aWbxjUwlKMqixLxLFPVIfkjocz2aoVjnMdM7JCxKEMk=; b=j T+UWfvxGHGpyCFkOTJPAHmtmRn5b1P1g/Km1c/8V/exfddmXu5PnfHuyumjVRfT6 qSMXco7nKRW2YmMTq2kJq6DsAzRM2JqkUDX6KctxWlcqix3ibzyVO9rSkNr+ZXLU fAnnUnrDO7buIirgiJTMvKBVHonocAJfZsO/hS5anbO65ntEUJs5tKEmNA0nfP39 vl6wGVNoQcLR0LdH0sommVdSgaLPE3G+Mc+bFY5LZ9sNqO/WrFklzrejXVd24BuC z86a1oL5NOkJEbQhFtoANs8i/q30r2V4z6n1tjhFFAF4rfkYIuNAJnZcL6w6d5ck R+vFzv7WNJTtPK/DhXkVA== 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= 1753140828; x=1753227228; bh=aWbxjUwlKMqixLxLFPVIfkjocz2aoVjnMdM 7JCxKEMk=; b=c7+7nMVfu7T3edQF/GoeBSLLbM6+DlNh58f2qsdrVucxK8e/uWy RabwZQ28IFAIKDX9AgrSZ4CcAkl1RYbYWiWO7nNBVqFEC2PQBHyEQvlk6hWaGO9x e57QA79t8ouBHgot5VchTkGovyOOXsYP4orI4X2xXhHTpfMUa040IuBwMaq9POpK xq2nGHiwzM8fZYM8mTvE8s8peXTg+CDXA6qCxC6030Vmn8vqMC8W0k4YAaarlZmG rr30tl07zMWk09uzOmmvP8nKGuEuLiDFXSKT51/Npzgz4Z5p2HtblpMc4hUPpAT/ xISD+dmi+SyGS2VytS0OXEvgFpOUAvJyY1w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdejfeeflecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufgjfhffkfggtgesmhdtreertddtjeenucfhrhhomheptfhuugholhhfucet uggrmhhkohhvihgtuceorhhuugholhhfsegruggrmhhkohhvihgtrdhorhhgqeenucggtf frrghtthgvrhhnpeevkeekhfeuvdethedtjeejheduleduueeliedugfegveefjeekjeev tdetlefgveenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehruhguohhlfhesrggurghmkhhovhhitgdrohhrghdpnhgspghrtghpthhtohepfedp mhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjeeltddvfeesuggvsggsuhhgshdrgh hnuhdrohhrghdprhgtphhtthhopehprhiivghmhihslhgrfieskhgrmhhinhhskhhirdhs vgdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i88214938:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 21 Jul 2025 19:33:47 -0400 (EDT) From: Rudolf =?utf-8?Q?Adamkovi=C4=8D?= To: Eli Zaretskii , =?utf-8?Q?Przemys=C5=82aw?= Alexander =?utf-8?Q?Kami=C5=84ski?= Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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> Date: Tue, 22 Jul 2025 01:33:45 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79023 Cc: 79023@debbugs.gnu.org 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 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Rudolf Adamkovi=C4=8D writes: > [...], and indeed, and the code above resulted in 1098 allocations of > 4.72 MB, totaling ~5.18 GB, and they are all like these: [...] Okay, I could not let go before sleep and investigated further. See the attached patch. With it, the never-freed 5.18 GB of RAM is fixed for: (dotimes (x 1000) (let ((frame (make-frame-command))) (sleep-for 0.01) (delete-frame frame))) P.S. The remaining 5.22 - 5.13 ~=3D 100 MB is wasted due to bugs elsewhere. Rudy --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-NS-Release-EmacsView-and-EmacsLayer-when-deallocatin.patch >From 99f8178c42b5a511a81be79256d629925375c5ff Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= Date: Tue, 22 Jul 2025 01:10:26 +0200 Subject: [PATCH] NS: Release EmacsView and EmacsLayer when deallocating EmacsWindow * src/nsterm.m: (ns_free_frame_resources, [EmacsView dealloc]): When deallocating EmacsWindow, release both its view (EmacsView) and its backing layer (EmacsLayer). When making and deleting 1000 frames in a loop, using (make-frame-command) and (delete-frame) respectively, along with (sleep-for 0.01) in between, the never-freed RAM goes from 5.18 gigabytes to "only" about 100 megabytes, which are wasted due to bugs elsewhere. --- src/nsterm.m | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/nsterm.m b/src/nsterm.m index 003aadb9782..54e5a71f7f6 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -1636,7 +1636,10 @@ Hide the window (X11 semantics) [f->output_data.ns->miniimage release]; [[view window] close]; + + /* Uninstall and release the view. */ [view removeFromSuperview]; + [view release]; xfree (f->output_data.ns); f->output_data.ns = NULL; @@ -6757,6 +6760,11 @@ - (void)dealloc if (fs_state == FULLSCREEN_BOTH) [nonfs_window release]; + + /* Release the backing layer. */ + EmacsLayer *layer = (EmacsLayer *)[self layer]; + [layer release]; + [super dealloc]; } -- 2.39.5 (Apple Git-154) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable --=20 "Logic is a science of the necessary laws of thought, without which no employment of the understanding and the reason takes place." --- Immanuel Kant, 1785 Rudolf Adamkovi=C4=8D [he/him] http://adamkovic.org --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 22 08:39:10 2025 Received: (at 79023) by debbugs.gnu.org; 22 Jul 2025 12:39:10 +0000 Received: from localhost ([127.0.0.1]:36147 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ueCH0-0004ts-7B for submit@debbugs.gnu.org; Tue, 22 Jul 2025 08:39:10 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53990) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ueCGw-0004tP-T2 for 79023@debbugs.gnu.org; Tue, 22 Jul 2025 08:39:07 -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 1ueCGq-0005Xu-Vr; Tue, 22 Jul 2025 08:39:01 -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=Y9vZaPc1+kh0TsJNCpwtJ32x/RYGa15YUq/2GYRwmg4=; b=hWs6jr5cxj2XcBsxCHf/ 7Zns3CTBk0xe7/dslU7NWE97qpqK9mRtZO7cJLSuogvnd3wz86o+zmoK98IWg0FdKbo30F4u5K1HJ DB3LC5MmHsfVyc+g6WlxNiAnj9QuXDWVXOdGG3aS3DyLujMRrpkapl1ORWEVslzxiWKTj324ASe+q HneF83Cx9gZAv2nZHEjDK1wVzre83/tdk1OfU0728mQnWyd8XJiiwOeaqwX8nUuZsgOPbrd4ldXem YHk5nweiulIghokEwvOf/t++MU1estUFM/zgkqBx9SVMtgAm6L6snn7UlR2/Bo8/oM5Iz+j7BG2CA Cj1YpkfhTOJN9A==; Date: Tue, 22 Jul 2025 15:38:56 +0300 Message-Id: <86ms8w9z8f.fsf@gnu.org> From: Eli Zaretskii To: Rudolf =?utf-8?Q?Adamkovi=C4=8D?= In-Reply-To: (message from Rudolf =?utf-8?Q?Adamkovi=C4=8D?= on Mon, 21 Jul 2025 21:16:34 +0200) Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79023 Cc: 79023@debbugs.gnu.org, przemyslaw@kaminski.se 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: Rudolf Adamkovič > Cc: 79023@debbugs.gnu.org > Date: Mon, 21 Jul 2025 21:16:34 +0200 > > Eli Zaretskii writes: > > > Then let's hear from other macOS users: does anyone else who uses > > Emacs on macOS have similar experience wrt the Emacs memory footprint? > > +1 I am on MacOS and my Emacs uses 2-4 GB RAM when in light use. > > P.S. Not sure if this is relevant but: > > Reproduction steps: > > 1. emacs -Q > 2. evaluate in *scratch* the form: > > (dotimes (x 1000) > (let ((frame (make-frame-command))) > (sleep-for 0.01) > (delete-frame frame))) > > Expected: > > Emacs uses ~60 MB of RAM (again), per the Activity Monitor. FTR: that's what I see here (not on macOS). So this is definitely macOS-specific. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 23 11:00:44 2025 Received: (at 79023) by debbugs.gnu.org; 23 Jul 2025 15:00:44 +0000 Received: from localhost ([127.0.0.1]:50796 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ueaxX-0005WV-Ic for submit@debbugs.gnu.org; Wed, 23 Jul 2025 11:00:43 -0400 Received: from fhigh-b3-smtp.messagingengine.com ([202.12.124.154]:56303) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ueaxV-0005WB-1b for 79023@debbugs.gnu.org; Wed, 23 Jul 2025 11:00:41 -0400 Received: from phl-compute-01.internal (phl-compute-01.phl.internal [10.202.2.41]) by mailfhigh.stl.internal (Postfix) with ESMTP id 6ED1D7A1A0D; Wed, 23 Jul 2025 11:00:35 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Wed, 23 Jul 2025 11:00:35 -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=1753282835; x=1753369235; bh=ZM1ZUhTkXX R+oTlXZghMnM042SWBIVBU1rjXfVW8pww=; b=n4NBI9iufR0IGyWgpP4AmE9oE1 o0NcNen7jWalZdjsa27DX1UVcPZMAEuSVMGqH/7FENqVafURLHmMkuF5UXMMrhO9 edx4+A1Pk5SLG52NyGymJFIjKfOokMhLXjeaqT50sA/40E7kcHKB7lM6YC+3UUnA 9zFIv7qZ+dg0i+laX492lgqUhcnUJ3QmVvZ4CtyvB/ScGnWlg7snXVKVgPTmSPT7 BRRMiuBUwOlZ5qZyTUqw9UfEMPbp5yKeVgjQdwaw5Y/m1VNr+uIQIKU0Eti7G/1/ q6AG/9Y1rSK9qxANW9KjB7cQ44Srs128nhDbW6SQ36Wtaic6BMXJAvwM2gEg== 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= 1753282835; x=1753369235; bh=ZM1ZUhTkXXR+oTlXZghMnM042SWBIVBU1rj XfVW8pww=; b=mU6SP+RyUa8hd8A9fqLULevWtadYDk1oagAhomXlGFAs58lJr8p 6jqSDUE80ReLbNEPyVSiZmXvqW45OeH1ZhYB7DHYxMOWw80IILmMiFGlDgJUJgox SLD+Ov72eF0RENPunOiAUJYCH/DRj+i1GN8bWfbyURAKqRmimgFefuH+niY+tlT9 G/4AqWKqjsn6NJe2Ecok9wAx5KJnsKGAEPe1FVOqoH9aStXJskdfUeYWXd8NgYTH aXH0SorQb3WBWTMh+erNIdDX9jnjFjCu8Y3+grZYodADiHfEExU85fGFM55aGlpJ pacds3r8qZpbwJbEnBAiSP8X0PeX/2MpQaw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdejkedtlecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffoffkjghfgggtsehmtdhmreertdejnecuhfhrohhmpefrrhiivghmhihs lhgrficutehlvgigrghnuggvrhcumfgrmhhiknhskhhiuceophhriigvmhihshhlrgifse hkrghmihhnshhkihdrshgvqeenucggtffrrghtthgvrhhnpeeiudejhfdtteegtdefkeef teeuvdegheeiudevkeeiieeljeetkedtvefgkeeiffenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehprhiivghmhihslhgrfieskhgrmhhinhhs khhirdhsvgdpnhgspghrtghpthhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpth htoheprhhuugholhhfsegruggrmhhkohhvihgtrdhorhhgpdhrtghpthhtohepvghlihii sehgnhhurdhorhhgpdhrtghpthhtohepjeeltddvfeesuggvsggsuhhgshdrghhnuhdroh hrgh X-ME-Proxy: Feedback-ID: i08494404:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 23 Jul 2025 11:00:33 -0400 (EDT) From: =?utf-8?b?UHJ6ZW15c8WCYXcgQWxleGFuZGVyIEthbWnFhHNraQ==?= To: =?utf-8?q?Rudolf_Adamkovi=C4=8D?= Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) Date: Wed, 23 Jul 2025 17:00:31 +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> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_MailMate_8C4A4951-FF08-4938-B595-EE0F1B56D919_=" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79023 Cc: Eli Zaretskii , 79023@debbugs.gnu.org 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_8C4A4951-FF08-4938-B595-EE0F1B56D919_= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 22 Jul 2025, at 1:33, Rudolf Adamkovi=C4=8D wrote: > P.S. The remaining 5.22 - 5.13 ~=3D 100 MB is wasted due to bugs elsewh= ere. I found the source and I don't like it. Spoiler alert: it's [NSApp run] i= nvocations. Critical functions/methods (ns_select_1/ns_read_socket_1) are draining th= e events in the run loop by calling [NSApp run]. As far as I understand ns_select_1 should be replacement for Linux' psele= ct, so why it calls run is puzzling at least. Because of this calls in many different things are happening. ns_select_= 1 might or might not release outerpool but events processing inside these= loops still can try to allocate fonts, menus and all kinds of data. Whic= h should be deallocated, but some objects are made for deallocation on Li= sp and not handled. But the worst thing I found is that there are hundreds of immediatelly ki= lled CGContext's etc. Why? In cases where pool draining DOES happen the i= nner application gets a clean slate and rebuilds from scratch all view ob= jects be able to process event queue. So even if autoreleased a single n= s_select_1 spawn might cause a 6mb allocation while creating IOSurface an= dredisplaying and redrawing even though it's never used. I figured that maybe never reinitializing the autorelease pool during run= loop would help, but I found that internal mechanism for processing Emacs= Event rellies on modifying the current event in the processing queue... = (which should be empty sometimes on autoinitialize, but since events come= at rapid rate, this is not guaranteed). That results in events modified.= I think that bug I observed, where Emacs was hanging on ns_select_1 coul= d be the reason - interrupt happened but the interrupt was rewritten to e= macs_event and here we go. It would also explain small annoyances, microh= angs, lack of responsiveness etc. After multiple attempts I finally found something that works - made a sim= ple lock on layout rendering which seems to keep things in check (note th= at discarded events are pointless anyway, because those discarded ones wo= uld trigger on re-allocated instance so not visible anyway). This patch has downside of making resize "weird". Best, Przemys=C5=82aw Alexander Kami=C5=84ski --=_MailMate_8C4A4951-FF08-4938-B595-EE0F1B56D919_= Content-Disposition: attachment; filename=render_block.patch Content-ID: <0525DEBF-A5A0-436A-9FFC-104BE3C167F5@kaminski.se> Content-Type: application/octet-stream; name=render_block.patch Content-Transfer-Encoding: base64 --=_MailMate_8C4A4951-FF08-4938-B595-EE0F1B56D919_=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 29 19:32:20 2025 Received: (at 79023) by debbugs.gnu.org; 29 Jul 2025 23:32:20 +0000 Received: from localhost ([127.0.0.1]:37114 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ugtnw-00065i-1F for submit@debbugs.gnu.org; Tue, 29 Jul 2025 19:32:20 -0400 Received: from fhigh-a1-smtp.messagingengine.com ([103.168.172.152]:33895) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ugtns-00065K-V9 for 79023@debbugs.gnu.org; Tue, 29 Jul 2025 19:32:17 -0400 Received: from phl-compute-06.internal (phl-compute-06.phl.internal [10.202.2.46]) by mailfhigh.phl.internal (Postfix) with ESMTP id BD2C8140294F; Tue, 29 Jul 2025 19:32:11 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Tue, 29 Jul 2025 19:32:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adamkovic.org; 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=fm1; t=1753831931; x=1753918331; bh=3hozr8+C4UxpdpsY8x7vv5Vjha5Bn1xw HgcmsT8NKgk=; b=dJfawHYiQCdX0mQq8mnr+0bB8IUltjVrQSKZGLsPSoL7dd85 1CpVG4JeLpRSmmnID3XlQMJq9CWk3uUxwcp24Jiah/KPN43R0CR0EAuZoPOhICGD KQCILXuhj5O3kEqeLrBjeOxOkKmVXKQC0hlvR7PNOvbMW6cHxNBLjeArEiAGwhgF PWp8PNpgLUujmz9DceT94EGI14xf0Cw/hvmEg4mxhRNUd6yLWBdteOsPyJytFxX0 5763u978RQXoQcA4+IunmkP4bpQS0SiZSjW2JjmqLIvKaGzyYlN/m4xnYrif3qnf +ITazqZAq2rAtRPm1Cvs6PMoJMUn9aXvG7mSPA== 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=fm3; t=1753831931; x= 1753918331; bh=3hozr8+C4UxpdpsY8x7vv5Vjha5Bn1xwHgcmsT8NKgk=; b=g ACkco5nlQoS9cuZph2j1QwqPOkrDVvBF/OwOcXmxdzGbLi8u6Fi4KrGSCIMIY74H 08QKXhY9AK09mkLkwyDPhxdWnPQCZQrjdOtRJ3mqhW7q8JklJ/HRtBuAsrhRLZR5 SLsa4UUFEl/OOE9aWi6xD+zLyyu1uJOQB1hqRubP7a8QIUiQRpkO9tAQ+wPBp2Gz VdDfiBiJ95yXw+Xwk0tffGSjozugt2caEVEn5nlZfm1hNIsshvvTGwkkczaoyrD9 tpnv8lfhfWKTTRK2h2Btb/mEy1fdNsLGn3cq+Jd9qIRABh1s5/vnzWm6HNiH5wtl yY/SXD+2voHPrZSIn7aXw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdelieefkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufgjfhffkfggtgfgsehtqhertddttdejnecuhfhrohhmpeftuhguohhlfhcu tegurghmkhhovhhitgcuoehruhguohhlfhesrggurghmkhhovhhitgdrohhrgheqnecugg ftrfgrthhtvghrnhepieeuteehffdugffhgeegveehvedvtdekffelhfeuledugfetgfff ledthfdujeegnecuffhomhgrihhnpegruggrmhhkohhvihgtrdhorhhgnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhhuugholhhfsegruggr mhhkohhvihgtrdhorhhgpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpohhuth dprhgtphhtthhopeejledtvdefseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthht ohepphhriigvmhihshhlrgifsehkrghmihhnshhkihdrshgvpdhrtghpthhtohepvghlih iisehgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i88214938:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 29 Jul 2025 19:32:10 -0400 (EDT) From: Rudolf =?utf-8?Q?Adamkovi=C4=8D?= To: Eli Zaretskii Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) In-Reply-To: <86ms8w9z8f.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> <86ms8w9z8f.fsf@gnu.org> Date: Wed, 30 Jul 2025 01:32:09 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79023 Cc: 79023@debbugs.gnu.org, przemyslaw@kaminski.se 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 (-) Eli Zaretskii writes: > So this is definitely macOS-specific. Eli, what are the next steps here? The problem has been found, reproduced, analyzed, measured, patched, and re-measured. All that was done on the current MacOS. I did not test on GNUstep, as I do not have it installed. P.S. I also have another NS patch waiting since March 2025 in bug#77062. Rudy --=20 "I love deadlines. I love the whooshing noise they make as they go by." --- Douglas Adams, The Salmon of Doubt, 2002 Rudolf Adamkovi=C4=8D [he/him] http://adamkovic.org From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 30 07:58:41 2025 Received: (at 79023) by debbugs.gnu.org; 30 Jul 2025 11:58:42 +0000 Received: from localhost ([127.0.0.1]:40057 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uh5SD-0003hI-JY for submit@debbugs.gnu.org; Wed, 30 Jul 2025 07:58:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45116) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uh5SA-0003gy-F9 for 79023@debbugs.gnu.org; Wed, 30 Jul 2025 07:58:39 -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 1uh5S4-0000Zv-Q6; Wed, 30 Jul 2025 07:58:32 -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=TwGwM2uBc5ZWaih+DrQ5nKt7ScPu5ssgAAUm+5JeoWs=; b=DzuRLl1/Rn3TUL1FcCpO xtg01/9u/kxocSpC14r/8iXWreju15Ane401HihGRgg791dBzoJB9D32Yhuiy7fEiqh7daLT7D/gY 2L++w/RN9za4GyAIuuAo4w9hv69ERieQcJIHbVJfyer1Hfc4NIQEAyATLwY5TXkd+NCPqZY4Y0X8C o0YJ+TQabRPWu+m5H54llrwH5HqSIV2LPWMr7vD5qdrREqqyPcMUKMlQE89S5dMUJPkkaD4mh4dnp kXiN1KH9JHjZOcqPMuR9VE6QyOr0RrBJESBx7ZAc/2VU007MDIjygeNYq02ypr46MIWwoJp4302PK cthqCXPg0cp2FQ==; Date: Wed, 30 Jul 2025 14:58:30 +0300 Message-Id: <86a54lx53t.fsf@gnu.org> From: Eli Zaretskii To: Rudolf =?utf-8?Q?Adamkovi=C4=8D?= In-Reply-To: (message from Rudolf =?utf-8?Q?Adamkovi=C4=8D?= on Wed, 30 Jul 2025 01:32:09 +0200) Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) References: <5BA8A8B9-96CB-4823-836B-49CEBED77CEF@kaminski.se> <86ldopk5hq.fsf@gnu.org> <113CE362-63BF-4F13-845C-1DB8F6D8580C@kaminski.se> <86frexk2ds.fsf@gnu.org> <86ms8w9z8f.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79023 Cc: 79023@debbugs.gnu.org, przemyslaw@kaminski.se 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: Rudolf Adamkovič > Cc: przemyslaw@kaminski.se, 79023@debbugs.gnu.org > Date: Wed, 30 Jul 2025 01:32:09 +0200 > > Eli Zaretskii writes: > > > So this is definitely macOS-specific. > > Eli, what are the next steps here? As usual: . someone should post a patch . macOS users should run with the patch for a while and provide feedback . interested individuals should actively and routinely request feedback . after some time, we install the patch with whatever changes it accrues AFAIU, in this case what we should do now is more testing on more relevant platforms, and Someone™ should volunteer to track the testing and collect feedback/make changes to the patch, until we decide it's tested enough. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 04 14:10:52 2025 Received: (at submit) by debbugs.gnu.org; 4 Aug 2025 18:10:52 +0000 Received: from localhost ([127.0.0.1]:52620 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uize8-0003RJ-8f for submit@debbugs.gnu.org; Mon, 04 Aug 2025 14:10:52 -0400 Received: from lists.gnu.org ([2001:470:142::17]:54166) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uize4-0003Qv-Bc for submit@debbugs.gnu.org; Mon, 04 Aug 2025 14:10:49 -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 1uizdX-0000mD-MW for bug-gnu-emacs@gnu.org; Mon, 04 Aug 2025 14:10:20 -0400 Received: from fout-a7-smtp.messagingengine.com ([103.168.172.150]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uizdS-00037K-Em for bug-gnu-emacs@gnu.org; Mon, 04 Aug 2025 14:10:12 -0400 Received: from phl-compute-10.internal (phl-compute-10.phl.internal [10.202.2.50]) by mailfout.phl.internal (Postfix) with ESMTP id 1E781EC0537 for ; Mon, 4 Aug 2025 14:10:07 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-10.internal (MEProxy); Mon, 04 Aug 2025 14:10:07 -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 :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1754331007; x=1754417407; bh=8h9JWd5N4x NpBVJlRmnoeyfVevpff+xijBY9WZpIx8Y=; b=Njmd4Hr0mphYQTG57CQ106CZzM wXSYLD9sEtXC/7SmQTy8V360qKRcvm0V4P8n84kGYLv7KdCdCtujhGB6n3YijKtQ NGnLY9WlIvRSi2kw/ksxyNCvb5lfX75tgDN1liBS52+xQfDZNf9oYLSLGfNCA4Tu t3m7gJ2LP9e1xpGS0NW4aHvFCXNER4uPaWLJFEXFVQwtueFgeIMaEgg6dfz/CuO4 hdwGqx4yeNdVkjZTZQTBjg4JyYzVSnOph4kkKfZXvS4bPqlYLCoTYYTBVIzLLqPZ SciiKoeFPTyxXaTVxxS1d2F/8HGxaX//fttWcxmfGy5lpZR5hzu5zVCgSlvg== 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: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=fm3; t= 1754331007; x=1754417407; bh=8h9JWd5N4xNpBVJlRmnoeyfVevpff+xijBY 9WZpIx8Y=; b=nPFCnqF5L9Pz53RDUwFBBzPs5DBRFqCv3qlwhwz/AeE1OJPQbCS VxMGW02P2uCYoZ7V67FJc32V+mp7v8mIdThA5I9VuhNUVPWbpnCplyFGUSsmqZG5 2acI4uu/4y574n38jK/9H4Vxfg4Q4oaT2ghI4dnMwrsX68tKiSriYLVX8MT7awkL kgH98Idfchp1Hafn6fYAOWRCIgOdPfJNEVlCdEwPtPK/Jrd0/cnwcVmLrAFM6Lmj ja3+2RQKdNi6fjTlr+dJ/5APEeefU4ms2tOFksBcdzRciyaVyt4YaViklxW5d3dL BaNb9L99QEKj/LtiOpqxLkBJzId4NpKA9nQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdduuddvleejucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpefhvffujghffffkgggtsehmtderredttd ejnecuhfhrohhmpefrrhiivghmhihslhgrficutehlvgigrghnuggvrhcumfgrmhhiknhs khhiuceophhriigvmhihshhlrgifsehkrghmihhnshhkihdrshgvqeenucggtffrrghtth gvrhhnpeeuiedtueejhefhueelfedtjeeutdevieetieekfeejteduleeggfekudegheeg hfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehprh iivghmhihslhgrfieskhgrmhhinhhskhhirdhsvgdpnhgspghrtghpthhtohepuddpmhho uggvpehsmhhtphhouhhtpdhrtghpthhtohepsghughdqghhnuhdqvghmrggtshesghhnuh drohhrgh X-ME-Proxy: Feedback-ID: i08494404:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 4 Aug 2025 14:10:06 -0400 (EDT) From: =?utf-8?Q?Przemys=C5=82aw_Alexander_Kami=C5=84ski?= To: bug-gnu-emacs@gnu.org Subject: Re: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) In-Reply-To: <5BA8A8B9-96CB-4823-836B-49CEBED77CEF@kaminski.se> References: <5BA8A8B9-96CB-4823-836B-49CEBED77CEF@kaminski.se> Date: Mon, 04 Aug 2025 20:10:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=103.168.172.150; envelope-from=przemyslaw@kaminski.se; helo=fout-a7-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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_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-Debbugs-Envelope-To: submit 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 (/) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'm attaching the patch that looks promising (from local instrumentation): Changes: - render_block mechanism when doing "inner" run loops - don't CGContextFlush manually (documentation recommends to leave window renderer to handle that) - some small fixes in releases (toolbar) - niling Emacs' frame struct on window dealloc - it should be garbagged but it seems something is still attached to the ref and cannot be GCed Known issues: - Can't get resizing as it's chicken-and-egg problem - drag redraws and redraw reads on socket (which blocks redraws) Other remarks: - Increasing number of buffers in "double buffering" prevents leaks and memory allocation, but I didn't include it in the patch (e.g. not array of 2, but array of 4 or 6) Best, Przemys=C5=82aw Alexander Kami=C5=84ski --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=ns.patch Content-Description: ns.patch diff --git a/ns.patch b/ns.patch new file mode 100644 index 0000000000..e69de29bb2 diff --git a/src/nsterm.m b/src/nsterm.m index 30a35bdd5b..544ec409a3 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -78,6 +78,25 @@ static EmacsMenu *mainMenu; #endif +static volatile int render_blocked = 0; +INLINE void +block_render (void) +{ + render_blocked++; +} +INLINE bool +render_blocked_p (void) +{ + return render_blocked > 0; +} +INLINE void +unblock_render (void) +{ + render_blocked--; +} + + + /* The last known monitor attributes list. */ static Lisp_Object last_known_monitors; @@ -1637,6 +1656,7 @@ [[view window] close]; [view removeFromSuperview]; + [view release]; xfree (f->output_data.ns); f->output_data.ns = NULL; @@ -4956,8 +4976,9 @@ to ourself, otherwise [NXApp run] will never exit. */ send_appdefined = YES; ns_send_appdefined (-1); - + block_render(); [NSApp run]; + unblock_render(); } nevents = n_emacs_events_pending; @@ -5099,7 +5120,9 @@ block_input (); ns_init_events (&event); + block_render(); [NSApp run]; + unblock_render(); ns_finish_events (); if (nr > 0 && readfds) @@ -6839,6 +6862,13 @@ if (fs_state == FULLSCREEN_BOTH) [nonfs_window release]; + + // Don't reuse inner frame as on NS cleanup isn't complete + emacsframe = nil; + + EmacsLayer *layer = (EmacsLayer *)[self layer]; + [layer release]; + [[self menu] release]; [super dealloc]; } @@ -9033,7 +9063,6 @@ #if defined (NS_IMPL_COCOA) && MAC_OS_X_VERSION_MIN_REQUIRED >= 101400 CGContextRef context = [(EmacsLayer *)[self layer] getContext]; - CGContextFlush (context); double scale = [[self window] backingScaleFactor]; int bpp = CGBitmapContextGetBitsPerPixel (context) / 8; @@ -9084,7 +9113,7 @@ appears to be safe to call redisplay here. */ - (void)layoutSublayersOfLayer:(CALayer *)layer { - if (!redisplaying_p && FRAME_GARBAGED_P (emacsframe)) + if (!redisplaying_p && FRAME_GARBAGED_P (emacsframe) && !render_blocked_p()) { /* If there is IO going on when redisplay is run here Emacs crashes. I think it's because this code will always be run @@ -9588,8 +9617,9 @@ NSTRACE ("[EmacsWindow dealloc]"); /* We need to release the toolbar ourselves. */ + [[self toolbar] release]; [self setToolbar: nil]; - [[self toolbar] release]; + /* Also the last button press event . */ if (last_drag_event) @@ -10994,7 +11024,6 @@ if (!context) return; - CGContextFlush (context); CGContextRelease (context); context = NULL; --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 11 09:36:44 2025 Received: (at 79023) by debbugs.gnu.org; 11 Aug 2025 13:36:44 +0000 Received: from localhost ([127.0.0.1]:47719 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ulShg-0007GN-7U for submit@debbugs.gnu.org; Mon, 11 Aug 2025 09:36:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59582) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ulShb-0007Fy-1x for 79023@debbugs.gnu.org; Mon, 11 Aug 2025 09:36:39 -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 1ulShU-0005aO-4j; Mon, 11 Aug 2025 09:36:32 -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=d+6MSwqFG7vZazNma1kHvScgTsXQdQR1EWlHzcOzy5g=; b=mYffTUKM06IU28AOJqYv 7F77vXD6iA7FzKR4R/anA0aEre8OgzOptRKEwMkj1MNVs6D9GEcfuld/vN2S4miD6l9MZ0se83Ibc NMybiMhZApNEkUG3PdrsHTEUfb3DdELIPQxCmlGk80x6/hNgNbgWv0qVlkW7PL6pWB2NS7/Svrh+g F+2R+x999PSQl49jtFkIeWgjnxOMtOwxgGmRvh5+rP9PFP4gsveCewrLiWbRTgE/QI2BnsqZ4Fm1K Yh2phFHDqYUQfrTwWz9NZQu/pLWIpSi/IXM3Z2EgncOGidOyMgSkrOAbWfcf8iXIgigzf+AW4uV8j w6vCDSsXxS1RpA==; Date: Mon, 11 Aug 2025 16:36:27 +0300 Message-Id: <86bjomaskk.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?Przemys=C5=82aw?= Alexander =?utf-8?Q?Kami=C5=84ski?= In-Reply-To: (alexander@kaminski.se) Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) References: <5BA8A8B9-96CB-4823-836B-49CEBED77CEF@kaminski.se> <86ldopk5hq.fsf@gnu.org> <113CE362-63BF-4F13-845C-1DB8F6D8580C@kaminski.se> <86frexk2ds.fsf@gnu.org> <86ms8w9z8f.fsf@gnu.org> <86a54lx53t.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79023 Cc: rudolf@adamkovic.org, 79023@debbugs.gnu.org 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: Mon, 11 Aug 2025 14:09:21 +0200 > > > I was doing some allocation debugging (it's a build with render block & > release fixes). It seems I found the problem (30 minute non -Q instance). > > 654.03 MB 69.0% 44835 macfont_list > 654.03 MB 69.0% 44835 font_list_entities > 654.03 MB 69.0% 44835 font_find_for_lface > 489.50 MB 51.6% 44541 fontset_find_font > 489.50 MB 51.6% 44541 fontset_font > 489.50 MB 51.6% 44541 face_for_char > 305.78 MB 32.2% 5658 FACE_FOR_CHAR > 179.89 MB 18.9% 172 FACE_FOR_CHAR > 164.53 MB 17.3% 294 font_load_for_lface > > I have approx. 500 different fonts which I suppose would explain 10KB > per allocation. I will check if I can release those cleanly. This is supposed to cons a list (a Lisp_Object) of relevant fonts, which is then reclaimed by GC after face_for_char returns (because there are no references to it). Is that not what happens on macOS? From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 11 11:10:35 2025 Received: (at 79023) by debbugs.gnu.org; 11 Aug 2025 15:10:35 +0000 Received: from localhost ([127.0.0.1]:49761 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ulUAT-0003uV-OA for submit@debbugs.gnu.org; Mon, 11 Aug 2025 11:10:35 -0400 Received: from fhigh-b8-smtp.messagingengine.com ([202.12.124.159]:44685) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ulRLI-0002nE-Sr for 79023@debbugs.gnu.org; Mon, 11 Aug 2025 08:09:36 -0400 Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfhigh.stl.internal (Postfix) with ESMTP id 942AF7A0020; Mon, 11 Aug 2025 08:09:26 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-03.internal (MEProxy); Mon, 11 Aug 2025 08:09:26 -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=fm1; t=1754914166; x=1755000566; bh=vcODTr1jE9vz5nSf567QEDLt9zXg9Il2GALT3aev77Q=; b= d8TnBxxwpZ1EG3ErUkTxBVuRv1qiRxcjdsBu2b99ZrPxX4zmUPVQLka+MtIUpLrM YI/F4Xv4LZG2qBizrcg78WPkA4PXtOW+OpA3mGoxk4VDFMwf1xxB3wrg3MbnSp5o KcilT2oryhpnqC9b1bOciHf/7IUHTiis/5fLabNb0pau/5AUcYyPOBKED5afC1i/ HJs0ghd1OijNDD5KWNMUJ9PhK1TCkOsnVBAX/3atSzxFKDE7hwmscRN1OHmjfcIu m1SyKtJlh2frOYavDS4x9zY3lmsAZ0nUOyedamgmobTvaytQJZTxi6+7MUIUfLkC IpWyBBBmG4L5pEPBGP0bVA== 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=fm3; t=1754914166; x= 1755000566; bh=vcODTr1jE9vz5nSf567QEDLt9zXg9Il2GALT3aev77Q=; b=a mLRk1TXhQ+gY0OrMke45/VekM6PjjcuD1GD56+QXuwxm0sgbpVJmunBGgbvZPka6 eaS93GqXmI1qVyXr8+kDVcHWT/KUvL+l4FdukGovGjs+9gFNfATOX1g1ikTMwHC3 A9T+13HrF7S8/nfd0PPvPWjZdd8QI2PB6fZen9hirMevTTNFhtUsY4MN68NgTFua EePNWLjE+TqkXgZdLV/nQGpiFfYHE3J6pUIIz7uQsQC9nL3W/QkyYraas9I1HCdS Jl6u3ZbntQB/tZaoq/kyE1w69h1Bgm/cRJZCwWpQCa54xWy+WgML/BBSMUWfUb7O ro15U+0H2U8weaxEjjJ/g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgddufedvgedvucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhephffvvefujghffffkgggtgfesthhqredttddtjeenucfhrhhomheprfhriigvmhih shhlrgifucetlhgvgigrnhguvghrucfmrghmihnkshhkihcuoegrlhgvgigrnhguvghrse hkrghmihhnshhkihdrshgvqeenucggtffrrghtthgvrhhnpedvveelveeltdelledtledu tedtleetffekhedtgfeivedvtdevleevfffhkeejvdenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhgvgigrnhguvghrsehkrghmihhnshhk ihdrshgvpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpohhuthdprhgtphhtth hopeejledtvdefseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtoheprhhuugho lhhfsegruggrmhhkohhvihgtrdhorhhgpdhrtghpthhtohepvghlihiisehgnhhurdhorh hg X-ME-Proxy: Feedback-ID: i282146b2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 11 Aug 2025 08:09:24 -0400 (EDT) From: =?utf-8?Q?Przemys=C5=82aw_Alexander_Kami=C5=84ski?= To: Eli Zaretskii , Rudolf =?utf-8?Q?Adamkovi=C4=8D?= Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) In-Reply-To: <86a54lx53t.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> <86ms8w9z8f.fsf@gnu.org> <86a54lx53t.fsf@gnu.org> Date: Mon, 11 Aug 2025 14:09:21 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79023 X-Mailman-Approved-At: Mon, 11 Aug 2025 11:10:30 -0400 Cc: 79023@debbugs.gnu.org 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 was doing some allocation debugging (it's a build with render block & release fixes). It seems I found the problem (30 minute non -Q instance). 654.03 MB 69.0% 44835 macfont_list 654.03 MB 69.0% 44835 font_list_entities 654.03 MB 69.0% 44835 font_find_for_lface 489.50 MB 51.6% 44541 fontset_find_font 489.50 MB 51.6% 44541 fontset_font 489.50 MB 51.6% 44541 face_for_char 305.78 MB 32.2% 5658 FACE_FOR_CHAR 179.89 MB 18.9% 172 FACE_FOR_CHAR 164.53 MB 17.3% 294 font_load_for_lface I have approx. 500 different fonts which I suppose would explain 10KB per allocation. I will check if I can release those cleanly. Best, Przemys=C5=82aw Alexander Kami=C5=84ski -- Pointers are real. They=E2=80=99re what the hardware understands. Somebody = has to deal with them. You can=E2=80=99t just place a LISP book on top of an x86 chip and hope that the hardware learns about lambda calculus by osmosis. -- James Mickens "The Night Watch" From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 11 11:52:20 2025 Received: (at 79023) by debbugs.gnu.org; 11 Aug 2025 15:52:20 +0000 Received: from localhost ([127.0.0.1]:49834 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ulUot-0005sj-2q for submit@debbugs.gnu.org; Mon, 11 Aug 2025 11:52:20 -0400 Received: from fout-b5-smtp.messagingengine.com ([202.12.124.148]:36529) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ulUFJ-0004BH-69 for 79023@debbugs.gnu.org; Mon, 11 Aug 2025 11:15:36 -0400 Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfout.stl.internal (Postfix) with ESMTP id 4951B1D00086; Mon, 11 Aug 2025 11:15:26 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Mon, 11 Aug 2025 11:15:26 -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=fm1; t=1754925326; x=1755011726; bh=yOr5DxatJFGVZDVT4FNpTDwrW6FCQ1uABIQMPawlxko=; b= B72KjoJQc5JKvaLZdSyfpkeqltrw62ggs4urNDGjbNGSRrTeYIUmYFYjPzhjieTH t95HTil0U4PQY+1vKGPF9VoKRRsFmOd5Su3V1ubvBVt7Vw/2tLbP5JuY2wUI12PC aligonLK7SWVQmolyou9oDpRYvpurGiczD88yN5i1Ud+jghKgvJiLH7GlNlPQtY1 s6G0c/f9EoDG+yeWyJLIhh+uXN9ucZRx2CmBGjwZs4TaRt9exB/hEX2Rt1FhTefz rC9cbCc+CkDsEoMJofS3hnvcIRKMGg4gMCjgCOqJ/yLbfjMvAYO2R6s5yPutK1d4 6k381sCtOXpMKCHb71TIGg== 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=fm3; t=1754925326; x= 1755011726; bh=yOr5DxatJFGVZDVT4FNpTDwrW6FCQ1uABIQMPawlxko=; b=e 8mIuXpdkcs+YLH2vDtZwqXwkojDgWmWIgB0dGatuK7yUbtGZn2wcBZadUNnNgaK6 VJ1n4dXlZ19AcpyMJ6PDDGmyPJbC2SHdkCPCY3poOUn6ppjlCVFsiS80tmh7WIrh aBaEGx0Es7bsdwW00yrireWafQvONrc4stwhwbNV/B9k02lQ+WsPy8A+hcT/F4eW bb+p8oLOJL5ckkRNdtRHlFx+DmGmB9n2prumPwGIhzrp5GxoZILHGA5YNdro3jcI U+tC0Xa9FK5S28spBuarBGnnjwAFAQIdHYw5pbWTdCqMolLyD7iJ29cXiLx02Zds H47pubA77bY7qCZJn0ZWw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgddufedvjeelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhephffvvefujghffffkgggtgfesthhqredttddtjeenucfhrhhomheprfhriigvmhih shhlrgifucetlhgvgigrnhguvghrucfmrghmihnkshhkihcuoegrlhgvgigrnhguvghrse hkrghmihhnshhkihdrshgvqeenucggtffrrghtthgvrhhnpedvveelveeltdelledtledu tedtleetffekhedtgfeivedvtdevleevfffhkeejvdenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhgvgigrnhguvghrsehkrghmihhnshhk ihdrshgvpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpohhuthdprhgtphhtth hopeejledtvdefseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtoheprhhuugho lhhfsegruggrmhhkohhvihgtrdhorhhgpdhrtghpthhtohepvghlihiisehgnhhurdhorh hg X-ME-Proxy: Feedback-ID: i282146b2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 11 Aug 2025 11:15:25 -0400 (EDT) From: =?utf-8?Q?Przemys=C5=82aw_Alexander_Kami=C5=84ski?= To: Eli Zaretskii Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) In-Reply-To: <86bjomaskk.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> <86ms8w9z8f.fsf@gnu.org> <86a54lx53t.fsf@gnu.org> <86bjomaskk.fsf@gnu.org> Date: Mon, 11 Aug 2025 17:15:22 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79023 X-Mailman-Approved-At: Mon, 11 Aug 2025 11:52:17 -0400 Cc: rudolf@adamkovic.org, 79023@debbugs.gnu.org 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 Mon, Aug 11, 2025 at 16:36:27 (+0300), Eli Zaretskii wrote: > This is supposed to cons a list (a Lisp_Object) of relevant fonts, > which is then reclaimed by GC after face_for_char returns (because > there are no references to it). Is that not what happens on macOS? No, and I think it was designed like that but a bug creeped in. Function macfont_create_family_with_symbol (macfont.m) uses symbol-to-font cache, but it seems that cache is set only when pat_desc exi= sts. Not sure why it's like that, but if that's not on purpose it would explain why reporting was inconsistent. I'm not seeing these allocations anymore at all. I started also changing=20 ns_can_use_native_image_api function (as it resulted in huge amount of small allocs). With those two changes I've seen merely 2MiB allocation afte= r my eshell colorful "fd" listing test - and it seems a legit one (some hook fir= ed). I need to clean up the code and split patches in smaller ones, hope to do have that soon. Best, Przemys=C5=82aw Alexander Kami=C5=84ski From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 11 14:48:01 2025 Received: (at 79023) by debbugs.gnu.org; 11 Aug 2025 18:48:01 +0000 Received: from localhost ([127.0.0.1]:50226 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ulXYu-00006I-Op for submit@debbugs.gnu.org; Mon, 11 Aug 2025 14:48:01 -0400 Received: from fhigh-a6-smtp.messagingengine.com ([103.168.172.157]:55407) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ulXYp-00005v-MQ for 79023@debbugs.gnu.org; Mon, 11 Aug 2025 14:47:57 -0400 Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfhigh.phl.internal (Postfix) with ESMTP id A294614000B1; Mon, 11 Aug 2025 14:47:48 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Mon, 11 Aug 2025 14:47:48 -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=fm1; t=1754938068; x=1755024468; bh=4O2o6qT5yy MyOqJVMznwR+hvaGKy4KjRz4ZXPSifz14=; b=fIjaJpyTrR1ggv9GbDEeLJs8ch B/A+2/OTnKM+oNWKZunU+vrjMiA66thq+1iv5/h7I7SMD2UVrNfFr561osjBX0yM dWFZaLGkkyU2nSXFf5Crpea1nGuTxkC2uFVZDhCuavGscKfirCf/xzzgWPb1HUlY aUEZFgfCHwLt2iCoZuk0AyFaKlicxheGaICqeU0vQDHiNfPvfv3e7O/iH2snMu5/ Ua5qSVvzLHUhO1RtcoFOaLmxxckpvO4RZGIJqDesPa5hHrUKWgaJvCbBDx7iaSyl 7cMq2Sd97Fr6HWRNqdAzMVOVyhQY9LdZJWSuGG3WyyNAR0MGLS44TwshE2Mg== 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=fm3; t= 1754938068; x=1755024468; bh=4O2o6qT5yyMyOqJVMznwR+hvaGKy4KjRz4Z XPSifz14=; b=Xd9YkRAQKyroVD2gyLhK4UqL0r4ZdOfwMDp2l+jFix3YmJC/B79 1B9B30POiVYqOtsecYx5AF/zB9UUK7Z74XaMf+c/uOog9YsdKNCGhcIzZExeplIr G4qAJRbba0i/yV1aSUTcq7qX/seomddwZHIKwkSr0Ve6wWjUF+WyGvRkkGeGUJId CeqMKqCbH2FFm39PzNDnkFxcKw9MmNnbr8O9ZvJmECJap3biC4tEomzKJHBB/rTh VC9MHRAcfScr1w0eWvY26BGuM32QC3QB8SFK3KHXdhiYkJtz0wXiEWzsRLUO3Dqt QdBX88YTflAIIqxQrFul3+Ps18AYdoIipqQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgddufeefvdduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhephffvvefujghffffkgggtsehmtderredttdejnecuhfhrohhmpefrrhiivghmhihs lhgrficutehlvgigrghnuggvrhcumfgrmhhiknhskhhiuceorghlvgigrghnuggvrheskh grmhhinhhskhhirdhsvgeqnecuggftrfgrthhtvghrnhepuddtuedugedvhfeigfetleeh tdeufedtgedvfeetuefhkeehleeigeehjedtteefnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomheprghlvgigrghnuggvrheskhgrmhhinhhskhhi rdhsvgdpnhgspghrtghpthhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoh epjeeltddvfeesuggvsggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopehruhguohhl fhesrggurghmkhhovhhitgdrohhrghdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i282146b2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 11 Aug 2025 14:47:47 -0400 (EDT) From: =?utf-8?Q?Przemys=C5=82aw_Alexander_Kami=C5=84ski?= To: Eli Zaretskii Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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> <86ms8w9z8f.fsf@gnu.org> <86a54lx53t.fsf@gnu.org> <86bjomaskk.fsf@gnu.org> Date: Mon, 11 Aug 2025 20:47:44 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79023 Cc: rudolf@adamkovic.org, 79023@debbugs.gnu.org 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 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'm attaching 6 patches (for easy review/scrutiny/integration). Those patches that I marked as tested was used by me for >1 week. * render_block_small.patch (significant impact, tested): This is similar patch to previous one, but it's minimal. It's crucial to avoid "blink" redraws. Still breaks smooth resizing, but frame-resize-pixelwise set to true makes it unnoticable. * cache_all_font_results.patch (significant impact, requires testing): This one prevents huge leak. I was trying to debug emacs-mac version (which has very deep traces for allocations, more 256 deep, which is limit for Instrumentations). That led to full malloc logging and discovery that macfont listings were allocating plenty of font-related data. Some of it it never cleared. I didn't test it and worry that caching "null" result might introduce some bugs, but it was hundreds of megabytes of allocations on -Q instance. * dont_flush_cg.patch (medium impact, tested): Based on documentation of CGContextFlush it should seldom be used, as it's much better to give OS possibility to decide when to flush. It prevents non-needed renders (and allocations etc.) * misc_releases.patch (small-mid impact, tested): This one is based on Rudolf Adamkovi=C4=8D patch with some minor extra releases and adjustments (like releasing an object before setting it to nil ;)) * ns_native_api_dict.patch (small-mid impact, needs testing): A small leak, but modified function had ~600_000 allocations after very short test runs. Seems like it wasted a lot of power, so I decided it should be checking dictionary hydrated at start and queried later instead of checking during runtime. I believe that high NSString allocation amount was indirectly caused by using autorelease pools. * nullify_frame.patch (small impact, tested): releases reference to a frame, as I've found traces in which resources were left behind, small leak. --- Fingers crossed that patches go through ;-) --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=nullify_frame.patch diff --git a/src/nsterm.m b/src/nsterm.m index b006b4d5dd..1510f74b8b 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -6839,6 +6839,9 @@ if (fs_state == FULLSCREEN_BOTH) [nonfs_window release]; + /* Don't reuse inner - cleanup is robust enough */ + emacsframe = nil; + [super dealloc]; } --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=ns_native_api_dict.patch diff --git a/src/nsimage.m b/src/nsimage.m index 8f1653d085..de2ae8aecf 100644 --- a/src/nsimage.m +++ b/src/nsimage.m @@ -56,9 +56,51 @@ ========================================================================== */ + +static CFDictionaryRef image_api_dict; +extern void +ns_image_init (void) +{ + if(image_api_dict) return; + NSArray *imageTypes = [NSImage imageTypes]; +Lisp_Object keys[] + = { Qnative_image, + Qjpeg, + Qpng, + Qgif, + Qtiff, +#ifndef HAVE_RSVG + Qsvg, +#endif +#ifndef HAVE_WEBP + Qwebp, +#endif + Qheic +}; +bool values[] + = { YES, + [imageTypes containsObject:@"public.jpeg"], + [imageTypes containsObject:@"public.png"], + [imageTypes containsObject:@"com.compuserve.gif"], + [imageTypes containsObject:@"public.tiff"], +#ifndef HAVE_RSVG + [imageTypes containsObject:@"public.svg-image"], +#endif +#ifndef HAVE_WEBP + [imageTypes containsObject: @"org.webmproject.webp"], +#endif + [imageTypes containsObject: @"public.heic"], +}; + image_api_dict = CFDictionaryCreate(NULL, (void *) keys, ( void *) values, 50, NULL,NULL); + +} + bool ns_can_use_native_image_api (Lisp_Object type) { +#ifdef NS_IMPL_COCOA + return (bool) (CFDictionaryGetValue(image_api_dict, type) || NO); +#endif NSString *imageType = @"unknown"; NSArray *types; @@ -67,32 +109,6 @@ if (EQ (type, Qnative_image)) return YES; -#ifdef NS_IMPL_COCOA - /* Work out the UTI of the image type. */ - if (EQ (type, Qjpeg)) - imageType = @"public.jpeg"; - else if (EQ (type, Qpng)) - imageType = @"public.png"; - else if (EQ (type, Qgif)) - imageType = @"com.compuserve.gif"; - else if (EQ (type, Qtiff)) - imageType = @"public.tiff"; -#ifndef HAVE_RSVG - else if (EQ (type, Qsvg)) - imageType = @"public.svg-image"; -#endif -#ifndef HAVE_WEBP - else if (EQ (type, Qwebp)) - imageType = @"org.webmproject.webp"; -#endif - else if (EQ (type, Qheic)) - imageType = @"public.heic"; - - /* NSImage also supports a host of other types such as PDF and BMP, - but we don't yet support these in image.c. */ - - types = [NSImage imageTypes]; -#else /* Work out the image type. */ if (EQ (type, Qjpeg)) imageType = @"jpeg"; @@ -104,7 +120,6 @@ imageType = @"tiff"; types = [NSImage imageFileTypes]; -#endif /* Check if the type is supported on this system. */ if ([types indexOfObject:imageType] != NSNotFound) diff --git a/src/nsterm.h b/src/nsterm.h index d9d16ffabd..342a38a126 100644 --- a/src/nsterm.h +++ b/src/nsterm.h @@ -1200,6 +1200,7 @@ /* From nsimage.m, needed in image.c. */ struct image; +extern void ns_image_init(void); extern bool ns_can_use_native_image_api (Lisp_Object type); extern void *ns_image_from_XBM (char *bits, int width, int height, unsigned long fg, unsigned long bg); diff --git a/src/nsterm.m b/src/nsterm.m index b006b4d5dd..c539832756 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -5787,6 +5787,7 @@ pthread_mutex_init (&select_mutex, NULL); } + ns_image_init(); ns_pending_files = [[NSMutableArray alloc] init]; ns_pending_service_names = [[NSMutableArray alloc] init]; ns_pending_service_args = [[NSMutableArray alloc] init]; --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=render_block_small.patch diff --git a/src/nsterm.m b/src/nsterm.m index b006b4d5dd..cd9ee9ebfe 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -78,6 +78,25 @@ static EmacsMenu *mainMenu; #endif +static volatile int render_blocked = 0; +INLINE void +block_render (void) +{ + render_blocked++; +} +INLINE bool +render_blocked_p (void) +{ + return render_blocked > 0; +} +INLINE void +unblock_render (void) +{ + render_blocked--; +} + + + /* The last known monitor attributes list. */ static Lisp_Object last_known_monitors; @@ -4956,8 +4975,9 @@ to ourself, otherwise [NXApp run] will never exit. */ send_appdefined = YES; ns_send_appdefined (-1); - + block_render(); [NSApp run]; + unblock_render(); } nevents = n_emacs_events_pending; @@ -5099,7 +5119,9 @@ block_input (); ns_init_events (&event); + block_render(); [NSApp run]; + unblock_render(); ns_finish_events (); if (nr > 0 && readfds) @@ -9084,7 +9106,7 @@ appears to be safe to call redisplay here. */ - (void)layoutSublayersOfLayer:(CALayer *)layer { - if (!redisplaying_p && FRAME_GARBAGED_P (emacsframe)) + if (!redisplaying_p && FRAME_GARBAGED_P (emacsframe) && !render_blocked_p()) { /* If there is IO going on when redisplay is run here Emacs crashes. I think it's because this code will always be run --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=cache_all_font_results.patch diff --git a/src/macfont.m b/src/macfont.m index 2a0b9aa255..cef4cf80ff 100644 --- a/src/macfont.m +++ b/src/macfont.m @@ -1152,9 +1152,10 @@ CTFontDescriptorCopyAttribute (desc, kCTFontFamilyNameAttribute); CFRelease (desc); } - macfont_set_family_cache (symbol, result); + CFRelease (pat_desc); } - + /* It's possible that we don't have have kCTFontFamilyNameAttribute for symbol, but still cache result */ + macfont_set_family_cache (symbol, result); return result; } --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=dont_flush_cg.patch diff --git a/src/nsterm.m b/src/nsterm.m index b006b4d5dd..057d876a35 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -9033,7 +9033,6 @@ #if defined (NS_IMPL_COCOA) && MAC_OS_X_VERSION_MIN_REQUIRED >= 101400 CGContextRef context = [(EmacsLayer *)[self layer] getContext]; - CGContextFlush (context); double scale = [[self window] backingScaleFactor]; int bpp = CGBitmapContextGetBitsPerPixel (context) / 8; @@ -10994,7 +10993,6 @@ if (!context) return; - CGContextFlush (context); CGContextRelease (context); context = NULL; --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=misc_releases.patch diff --git a/src/nsterm.m b/src/nsterm.m index b006b4d5dd..f1ea98b107 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -1637,6 +1637,7 @@ [[view window] close]; [view removeFromSuperview]; + [view release]; xfree (f->output_data.ns); f->output_data.ns = NULL; @@ -6839,6 +6840,11 @@ if (fs_state == FULLSCREEN_BOTH) [nonfs_window release]; + + /* Release layer and menu */ + EmacsLayer *layer = (EmacsLayer *)[self layer]; + [layer release]; + [[self menu] release]; [super dealloc]; } @@ -9588,8 +9594,9 @@ NSTRACE ("[EmacsWindow dealloc]"); /* We need to release the toolbar ourselves. */ + [[self toolbar] release]; [self setToolbar: nil]; - [[self toolbar] release]; + /* Also the last button press event . */ if (last_drag_event) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Best, Przemys=C5=82aw Alexander Kami=C5=84ski --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 11 20:07:18 2025 Received: (at 79023) by debbugs.gnu.org; 12 Aug 2025 00:07:18 +0000 Received: from localhost ([127.0.0.1]:50741 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ulcXt-0006p4-I7 for submit@debbugs.gnu.org; Mon, 11 Aug 2025 20:07:18 -0400 Received: from fhigh-a1-smtp.messagingengine.com ([103.168.172.152]:40583) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ulcXp-0006ok-9K for 79023@debbugs.gnu.org; Mon, 11 Aug 2025 20:07:15 -0400 Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.phl.internal (Postfix) with ESMTP id 34B401400166; Mon, 11 Aug 2025 20:07:07 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Mon, 11 Aug 2025 20:07:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adamkovic.org; 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=fm1; t=1754957227; x=1755043627; bh=kfLHvv9TwOQN6Idi0RJ6aVr8KABYqjX2 7dx3DkPtpC4=; b=C9QyM+ejQ2Xo6X5xwZHB/Qd2LIDmic+OcbErC+AM8djgnD4H 7Byxr5z4Wpjw923XVrJiGLtscy3oj+Yv1cOeXEY0HJAVMNM/21fSIU2UDh1cxctT 4mQ43mF/xOHX428BK1BRgwVLF1aEG07t6aGrqcU92SygOsAlsveV9X3ii6GVqzFP qbhfv5jasjxzHgfN/ND3nzh5+j6rQczwuubxSqQCpatlcWhAgg2J+Zv+yjG6NiWp o7duOvE8sWlpMXLNPcuFytdtAX/oSadqUIrbeG0Jtcl3bP4V87q1f4JsR4glCZZT jx/ImNi+AuZL19Pv0yc1uNQrDJPTQL+tpWyHOw== 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=fm3; t=1754957227; x= 1755043627; bh=kfLHvv9TwOQN6Idi0RJ6aVr8KABYqjX27dx3DkPtpC4=; b=S Ha6La9eUtumcVUn4p0uWyWjSb59ckRc6qnG4OPldfRAXl5Riawb7i/w1xLj/AWqi BXLiZbmCGmgUzaBHBVsTXviuBBcz+BpoR+mmTQL98vR4gTKjgqpDZLhuXSPTt+Z3 WEqiUEQApp+FUeRdNuCsU0BzlHcwBtxOBqQL1kCw+ovFQXfM3yblEDVRh/YeS5CW pSRO3K2dCCf7Ml7WLOIZIs44cr4iPQiybmfD7dml3BGHr2WKSlKEj5doXUPsWJqL MMflh89b15vaSm3EzggXQAj+6fwizWeiZyWBP7Q20kCb6vGE9Pr50xyTHq+L8Mz/ eojAjGdEpTXx+686rg+Gw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgddufeefkeehucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhephffvvefujghffffkgggtgfesthhqredttddtjeenucfhrhhomheptfhuugholhhf ucetuggrmhhkohhvihgtuceorhhuugholhhfsegruggrmhhkohhvihgtrdhorhhgqeenuc ggtffrrghtthgvrhhnpeeiueetheffudfghfeggeevheevvddtkefflefhueeludfgtefg ffeltdfhudejgeenucffohhmrghinheprggurghmkhhovhhitgdrohhrghenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehruhguohhlfhesrggu rghmkhhovhhitgdrohhrghdpnhgspghrtghpthhtohepfedpmhhouggvpehsmhhtphhouh htpdhrtghpthhtohepjeeltddvfeesuggvsggsuhhgshdrghhnuhdrohhrghdprhgtphht thhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopegrlhgvgigrnhguvghrsehkrg hmihhnshhkihdrshgv X-ME-Proxy: Feedback-ID: i88214938:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 11 Aug 2025 20:07:05 -0400 (EDT) From: Rudolf =?utf-8?Q?Adamkovi=C4=8D?= To: =?utf-8?Q?Przemys=C5=82aw?= Alexander =?utf-8?Q?Kami=C5=84ski?= , Eli Zaretskii Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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> <86ms8w9z8f.fsf@gnu.org> <86a54lx53t.fsf@gnu.org> <86bjomaskk.fsf@gnu.org> Date: Tue, 12 Aug 2025 02:07:04 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79023 Cc: 79023@debbugs.gnu.org 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 (-) Przemys=C5=82aw Alexander Kami=C5=84ski writes: > I'm attaching 6 patches (for easy review/scrutiny/integration). This is fantastic! When I was fixing view/layer leaks, I saw lots of other leaks, and the word "font" certainly caught my attention. :) I remember thinking, "I hope we [the community] will fix all these next, but let me first focus on the biggest leak [on my system]". So, I am super-happy someone is doing more! The NS port badly needs some serious love, or replacement. Its pixelated tool bar icons with white background in dark theme, barely responsive C-g, memory leaks, freezes, and crashes... scream "unmaintained". That is where we are. On my machine, NS often freezes, even `emacs -Q', when closing a frame with the mouse, using the standard WM "red circle" button. I have no reproducer, unfortunately. But, as a result, I close frames strictly with the keyboard, after losing edits multiple times. Similarly, when native compilation is doing its thing, Emacs is unusable because C-g is 99% ignored, even worse than normal, so I wait. The list goes on... So, thank you for improving the NS port! Rudy --=20 "Mathematics takes us still further from what is human into the region of absolute necessity, to which not only the actual world, but every possible world, must conform." --- Bertrand Russell, 1902 Rudolf Adamkovi=C4=8D [he/him] http://adamkovic.org From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 12 00:46:55 2025 Received: (at 79023) by debbugs.gnu.org; 12 Aug 2025 04:46:55 +0000 Received: from localhost ([127.0.0.1]:51131 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ulguV-0003Bf-A4 for submit@debbugs.gnu.org; Tue, 12 Aug 2025 00:46:55 -0400 Received: from mail-lf1-x130.google.com ([2a00:1450:4864:20::130]:44476) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1ulguO-0003BK-3Z for 79023@debbugs.gnu.org; Tue, 12 Aug 2025 00:46:51 -0400 Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-55b93104888so6460596e87.1 for <79023@debbugs.gnu.org>; Mon, 11 Aug 2025 21:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754974001; x=1755578801; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=x0GzHUElFFZcMhJ6rZnRnt0zPIiHSLT4XG+ioIGRokQ=; b=FvmYAFHD3rhoH9FJ5S547yIE0UwOISjLxbionWcOUdqENiz6bUV1J1qnSpBzsLGEs2 bIw8ahkXJFP4IMFv5DOFebEzBUpzwKKtA+rQvtrw6qwPULqqChyzh0xUhaRBh6EIsKU9 y/rtKBBHG3YWGST7CeGBpBFRIxk6vUg71ia1Q2inT0g5xzqj78K2+JPGbf0MWUyx9YFF 8xDrwozo9LQpMoim9McJRCjRTkK5pgxSRf07Cv0KkB0c+GmToc29WEy3UIWnL2o4mW2y wJn6tgj7d21E0HD0u5EAEy3urXsxaER87tVpZ1g+6aC6JRVCX1O+EGjucZ6bbh3DGmW+ krBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754974001; x=1755578801; h=content-transfer-encoding:mime-version:message-id:date:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=x0GzHUElFFZcMhJ6rZnRnt0zPIiHSLT4XG+ioIGRokQ=; b=w5CeqEX29dwhPH3YYSdbLQgbj16pMa2GoQwYIzYK72wuw3fq10IsNJX+FRb0+dvLQo j8kL2fT4FOK7BMzcJnzrHBUup9wqV39q3y00pd4ls/2WFPcmx1ZFPCm/YRHzHvqyNFSn 11oOnD36RDPICOhasO686AsvKWygATv6EW2zKsEQBraclRQTpb4qa+60ERtE/p7PaZYW qqFWShJt3yErykyuKGezP4FG44Vlc0amiLxcdbpIdcWh/3sEskNXQHVC0NSpheC+o0Sx qgTYiDzLwWwNXvyCKjaNQseZ9CZiWsjwTT8Yp8Zh0Ml0Qa433ViCicpzBhSwQXludpzY 3gKw== X-Forwarded-Encrypted: i=1; AJvYcCWYH0/phChl4GaY96E1goULNv/8Su/GGvJWDhfFLRMmd86gyI1tKOtuu4aoBmhlV5Mtg1lLEw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzACKWjNfZ8bbWdto4ni81ZgXHPRa5KLR8FrZkb9sUYiZYbN8y+ KkTZtnfz6hjIo0DEXKUWyf70UZeV1y6lgTGeENG+VBUIhjLCYf+LsCSK X-Gm-Gg: ASbGncucfUTlMa2EpuN86jjdrpEeVos5HUKDS8o8pNKTo/PIHRuyfhm7GIvi9EeUReU HfKTR1m035w6lFRWeZwh/jnaE6tOn/0atK/+Vg/y+wvgvtNHWllj3/81ABDOleL5rz9+Vv0IWB8 3bhH5RvbOk/2BVHOHdZ7L7xIiqn0FlVSSRQRc7xdnV/mxpkpItW5rIjqZuBrJGOT0OPPnZkL0pZ Qv2+kThmepvHKo01wxAeRyRb4LdsvshVnpSYQg8mfHxkTYGegiNeoSsDydh7INZOLWsEKIewyoU 1QURiE5NV4PwmX8OUKh1nW0g2QJIsQil3t1TZa7nbhf/8fbTZMrFzymq2iMR3sEg4MTjiDEspoW +q3HJ9+ndOajWeFGfkHVoAMtQzdCOzEROLMRtcD2UWalkDV1gnE17UEm3CKCamBIa9HJE7kL4m2 hb X-Google-Smtp-Source: AGHT+IHgxLR5mOJuiF3hF8QnF4fxl2HaRWfJ1aLst/Omz9YJXVg7bwJcS4EU/97IQ+BZ/lZyv2Bt6g== X-Received: by 2002:a05:6512:3c88:b0:558:f694:a65e with SMTP id 2adb3069b0e04-55cd761ff22mr587707e87.34.1754974000840; Mon, 11 Aug 2025 21:46:40 -0700 (PDT) Received: from localhost (0x5da5fbba.static.cust.fastspeed.dk. [93.165.251.186]) by smtp.gmail.com with UTF8SMTPSA id 2adb3069b0e04-55b88cb7e15sm4653156e87.176.2025.08.11.21.46.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Aug 2025 21:46:40 -0700 (PDT) From: "Paul D. Nelson" To: =?utf-8?Q?Przemys=C5=82aw?= Alexander =?utf-8?Q?Kami=C5=84ski?= Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) In-Reply-To: (alexander@kaminski.se) Date: Tue, 12 Aug 2025 06:46:38 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79023 Cc: rudolf@adamkovic.org, eliz@gnu.org, 79023@debbugs.gnu.org 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 (-) Przemys=C5=82aw Alexander Kami=C5=84ski writes: > I'm attaching 6 patches (for easy review/scrutiny/integration). > Those patches that I marked as tested was used by me for >1 week. I tried applying the patches for testing, but there were some clashes, e.g., nullify_frame.patch and misc_releases.patch both the modify the end of dealloc in nsterm.m, but the modifications do not stack. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 12 02:04:26 2025 Received: (at 79023) by debbugs.gnu.org; 12 Aug 2025 06:04:26 +0000 Received: from localhost ([127.0.0.1]:51275 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uli7V-00078h-H4 for submit@debbugs.gnu.org; Tue, 12 Aug 2025 02:04:26 -0400 Received: from fhigh-a5-smtp.messagingengine.com ([103.168.172.156]:45405) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uli7Q-00078M-Mb for 79023@debbugs.gnu.org; Tue, 12 Aug 2025 02:04:22 -0400 Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfhigh.phl.internal (Postfix) with ESMTP id 570131400170; Tue, 12 Aug 2025 02:04:15 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Tue, 12 Aug 2025 02:04: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=fm1; t=1754978655; x=1755065055; bh=egSrocqXnCOT+qELQ/KTpqp86j8JFNYbLwiBzvOpzc8=; b= P65Ahr4UnG95/TlfEPSYkzuiJ4LIGFL8OjjuoQXJwIpuI/1VD2LLrNUjtztkIri4 8szZ4LVOUwd5EqrsQwfoRrU4w9NaZhTELfTctD0INcTh01RhZvMnwD4gcSWBwfBJ X7nr7HFCxr5fh7aWST6u1DuamnA9D0xV2+tfzbjjpTYKlQS6piaiefhLu3FJ/U98 kB7F0HLlY9gFZ4clnCmfQIQF0OdHhbqCD6OB/jRJu0ZumqLSRbXBWEOQUpbFKQUn HbsI1lM1aaC6Bl19aReNZFQw3nP7GTyXEQXqF4PxBegbFeyrFAzx1y/HWpOab+22 uOBFIjEBRaHjvqgDJTSbSg== 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=fm3; t=1754978655; x= 1755065055; bh=egSrocqXnCOT+qELQ/KTpqp86j8JFNYbLwiBzvOpzc8=; b=j ovJ81YrwbRfWfchVtuM47bwpDoF4FNygFW+pAUrQUtul02gDFXYYMOznRbiB6BxW vxmUlzDyHQ6FYqMLfWxi1D6sjoZGSyh63/gEHFrMo+D3HrG2vnTzaQpB6J84CWYh A/Do0O5M2qrvflOv5M8PMlYH5hVBej8fscdAcYXsp9FBJVbLeDm873+bwvrXBEUP LgQm9btk3inBcnQBwYGYJFVlhJ12Q2csf/UrEpRnw+g2q9GGNjCLMwC9XmEhACK/ szDh0qr/fCs1z8Vue1VhTGTeFlbUfkUWKAyqs/y3scQ9LajNSPqkh4oMt+UH9pc/ vwx8kr3Hok+4dRWj0lh8g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgddufeegheeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhephffvvefujghffffkgggtgfesthhqredttddtjeenucfhrhhomheprfhriigvmhih shhlrgifucetlhgvgigrnhguvghrucfmrghmihnkshhkihcuoegrlhgvgigrnhguvghrse hkrghmihhnshhkihdrshgvqeenucggtffrrghtthgvrhhnpedvveelveeltdelledtledu tedtleetffekhedtgfeivedvtdevleevfffhkeejvdenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhgvgigrnhguvghrsehkrghmihhnshhk ihdrshgvpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpohhuthdprhgtphhtth hopeejledtvdefseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtohepvghlihii sehgnhhurdhorhhgpdhrtghpthhtoheprhhuugholhhfsegruggrmhhkohhvihgtrdhorh hg X-ME-Proxy: Feedback-ID: i282146b2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 12 Aug 2025 02:04:13 -0400 (EDT) From: =?utf-8?Q?Przemys=C5=82aw_Alexander_Kami=C5=84ski?= To: Rudolf =?utf-8?Q?Adamkovi=C4=8D?= , Eli Zaretskii Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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> <86ms8w9z8f.fsf@gnu.org> <86a54lx53t.fsf@gnu.org> <86bjomaskk.fsf@gnu.org> Date: Tue, 12 Aug 2025 08:04:10 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79023 Cc: 79023@debbugs.gnu.org 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 Tue, Aug 12, 2025 at 02:07:04 (+0200), Rudolf Adamkovi=C4=8D wrote: > Przemys=C5=82aw Alexander Kami=C5=84ski writes: >> I'm attaching 6 patches (for easy review/scrutiny/integration). > > This is fantastic! When I was fixing view/layer leaks, I saw lots of > other leaks, and the word "font" certainly caught my attention. :) I > remember thinking, "I hope we [the community] will fix all these next, > but let me first focus on the biggest leak [on my system]". I'll note that I found many red herrings when looking for leaks. MacOS defa= ult instrumentation tools are not recording stacks bigger than 256. NS version often has much bigger ones and emacs-mac relies on recursion (instead of start/stop) so the stacks are even deeper. Only after enabling MallockStackLogging at running the trace data is more visible. I have a Makefile that sets Malloc logging variable like this: malloc: export MallocStackLogging :=3D 1 malloc: export MallocStackLoggingNoCompact :=3D 1 malloc: export MallocScribble :=3D 1 malloc: export MallocPreScribble :=3D 1 malloc: $(EMACS_SOURCE_ROOT)/src/emacs -Q Visibility is much higher. I'm starting to wonder if I shouldn't write documentation about debugging techniques on MacOS, so more people could help - I suppose that many contributors know this trick, but I just started writing C last week ;) > So, I am super-happy someone is doing more! The NS port badly needs > some serious love, or replacement. Its pixelated tool bar icons with > white background in dark theme, barely responsive C-g, memory leaks, > freezes, and crashes... scream "unmaintained". That is where we are. Render block (i.e. no ability to start new event processing while keyboard input or socket read is happening) should help with some of the issues. C-g problem bothers me the most. It should be processed ASAP. Both render-blocking wrappers are in functions that prioritize processing them C-g so it might be better. If not - that will be my next "minor change". I'll start a new thread od emacs-devel about it. I wonder if shell-running sleep could work as a reproducer? I don't have Linux anywhere, but what's the expectation, that C-g would kill the process ASAP? As for crashes - understanding much more about what is happening in Emacs I've seen one and it was unsurprising one - accepting input while input was blocked (from mouse!). I didn't pay too much of an attention but this most likely still can happen. > On my machine, NS often freezes, even `emacs -Q', when closing a frame > with the mouse, using the standard WM "red circle" button. Experienced same. Checked this on 10h instance - no issues. I think it is resolved by nullifying patch. IMO reusing frames instead of creating new ones was simple expensive and nullyfing reference to the frame delegated cleanup to much faster (and thorough) OS. > So, thank you for improving the NS port! Even though I tried to quit it many times (mostly of boredom) I've been using Emacs for ~25 years. I'm happy to be able to give something back and make it better experience. Sloving non-trivial issue in a decades old software with minimal knowledge of used technology and architecture is also something that I consider a welcome "win", and ego points can not be overlooked ;-) Yet I'd like to thank you Rudy, as your enthusiasm helped me look into those issues. I tend to avoid zero-feedback problems as it usually mean an art for art's sake. Eli, also thank your for gently steering me out of the rabbit hole. You have great people skill. Best, Przemys=C5=82aw Alexander Kami=C5=84ski --=20 Pointers are real. They=E2=80=99re what the hardware understands. Somebody = has to deal with them. You can=E2=80=99t just place a LISP book on top of an x86 chip and hope that the hardware learns about lambda calculus by osmosis. -- James Mickens "The Night Watch" From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 12 02:10:43 2025 Received: (at 79023) by debbugs.gnu.org; 12 Aug 2025 06:10:43 +0000 Received: from localhost ([127.0.0.1]:51294 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uliDa-0007Up-Vy for submit@debbugs.gnu.org; Tue, 12 Aug 2025 02:10:43 -0400 Received: from fhigh-a5-smtp.messagingengine.com ([103.168.172.156]:57255) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uliDX-0007UY-Av for 79023@debbugs.gnu.org; Tue, 12 Aug 2025 02:10:39 -0400 Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50]) by mailfhigh.phl.internal (Postfix) with ESMTP id 00DCB1400172; Tue, 12 Aug 2025 02:10:34 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-10.internal (MEProxy); Tue, 12 Aug 2025 02:10:34 -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=fm1; t=1754979033; x=1755065433; bh=YhOnDJYDcg bEox/NgCxmFDqMK0GYStGhD/GR9Htt408=; b=Jj9VOs02Q+bjBp9qegaA8KkBMR 0W1nrmn8tBLmxAoyFKnskvYonY4c/b9cQr1SmU457FHLKR1sC2SqPwPWGNzAblMH /kcfmidTKJYW8FFHBQSKvcrcaQHfdriufi5YBxAUUq2mi8JDmwn2MXi7wpbR5fpl MjlzrSuJd9Dzh+mpXENHkTv3s3Q4svRb0peP82tNgnZffbS2vZH9kR2RbeAxzqXq /bbKVr0JtqUJhrtk8FldjFcLlt4ux4iFakfwERCWypIromgY/4/NnnPyyJ4ZiFiE leTg7tmrXlMdGQOBUkEYiCoPZBr2ibp0kWd8/O+fK5z1LRnrJIhJV4m8k1GQ== 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=fm3; t= 1754979033; x=1755065433; bh=YhOnDJYDcgbEox/NgCxmFDqMK0GYStGhD/G R9Htt408=; b=DJsjaYnwrE19J2DHQWNgqaqUAsFta8U9k4MRatsc7sS+7tcCeeT z92NhdjNFTajeh2fVXaEkh/I+koYf3QPBuxl7U9rv4A9Qqy5dqgM0dQNmINsf3Vk YVN0zzykM2iwkCHT3gqNI8+6V3g3GsMUszy6Iw7tkAmjn9g4qEWJTDswNrWIz+Mw u9BveWGhOH9xPxcPF9AzNDUel3ahw6wooQWl9Z0GgyJzG33nT0+WuSdLSVBH3ztQ 0ZAqw2q/Ni8U5Xa+zBGvyxqQyy4RpScs+Z1z8TXEE5ogM3VZmvIaOidgUmEZytKO wWhc8nbymZsIVmfyL3e8scoFQa1zpoGtiCQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgddufeegheejucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhephffvvefujghffffkgggtsehmtderredttdejnecuhfhrohhmpefrrhiivghmhihs lhgrficutehlvgigrghnuggvrhcumfgrmhhiknhskhhiuceorghlvgigrghnuggvrheskh grmhhinhhskhhirdhsvgeqnecuggftrfgrthhtvghrnhepuddtuedugedvhfeigfetleeh tdeufedtgedvfeetuefhkeehleeigeehjedtteefnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomheprghlvgigrghnuggvrheskhgrmhhinhhskhhi rdhsvgdpnhgspghrtghpthhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoh epjeeltddvfeesuggvsggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopehruhguohhl fhesrggurghmkhhovhhitgdrohhrghdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i282146b2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 12 Aug 2025 02:10:32 -0400 (EDT) From: =?utf-8?Q?Przemys=C5=82aw_Alexander_Kami=C5=84ski?= To: Eli Zaretskii Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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> <86ms8w9z8f.fsf@gnu.org> <86a54lx53t.fsf@gnu.org> <86bjomaskk.fsf@gnu.org> Date: Tue, 12 Aug 2025 08:10:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79023 Cc: rudolf@adamkovic.org, 79023@debbugs.gnu.org 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 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Version 2 of API dictionary. Previous one didn't take into account that some sub-processes might not initialize ns_term while still wanting to know native support for images which crashed subprocesses. This one initializes upon first usage (and is retained throughout lifetime). With all patches combined: Mem(Init->10h uptime->GC) - Mem(Init) =3D +- 1MiB Best, Przemys=C5=82aw Alexander Kami=C5=84ski --=20 Pointers are real. They=E2=80=99re what the hardware understands. Somebody = has to deal with them. You can=E2=80=99t just place a LISP book on top of an x86 chip and hope that the hardware learns about lambda calculus by osmosis. -- James Mickens "The Night Watch" --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=ns_native_api_dict_0002.patch diff --git a/src/nsimage.m b/src/nsimage.m index 8f1653d085..977694bab7 100644 --- a/src/nsimage.m +++ b/src/nsimage.m @@ -56,9 +56,57 @@ ========================================================================== */ +static CFDictionaryRef image_api_dict; + +/* + ns_image_init initializes native support image type cache-dict for + ns_can_use_native_image_api. Needs to be initialized ad-hoc since it's + possible that non-GUI subprocesses will use it. + + Without the cache-dict hundreds of thousands of small, persistent + NSString allocations are happening causing leak 40-60KiB leak per usage. +*/ + +static void ns_image_init (void) +{ + /* NSImage also supports a host of other types such as PDF and BMP, + but we don't yet support these in image.c. */ + NSArray *imageTypes = [NSImage imageTypes]; + Lisp_Object keys[] = { Qnative_image, Qjpeg, Qpng, Qgif, Qtiff, +#ifndef HAVE_RSVG + Qsvg, +#endif +#ifndef HAVE_WEBP + Qwebp, +#endif + Qheic }; + bool values[] = { + YES, + [imageTypes containsObject:@"public.jpeg"], + [imageTypes containsObject:@"public.png"], + [imageTypes containsObject:@"com.compuserve.gif"], + [imageTypes containsObject:@"public.tiff"], +#ifndef HAVE_RSVG + [imageTypes containsObject:@"public.svg-image"], +#endif +#ifndef HAVE_WEBP + [imageTypes containsObject:@"org.webmproject.webp"], +#endif + [imageTypes containsObject:@"public.heic"], + }; + image_api_dict + = CFDictionaryCreate (NULL, (void *) keys, (void *) values, 50, + NULL, NULL); + image_api_dict = CFRetain (image_api_dict); +} + bool ns_can_use_native_image_api (Lisp_Object type) { +#ifdef NS_IMPL_COCOA + if(!image_api_dict) ns_image_init(); + return (bool) (CFDictionaryGetValue(image_api_dict, type) || NO); +#endif NSString *imageType = @"unknown"; NSArray *types; @@ -67,32 +115,6 @@ if (EQ (type, Qnative_image)) return YES; -#ifdef NS_IMPL_COCOA - /* Work out the UTI of the image type. */ - if (EQ (type, Qjpeg)) - imageType = @"public.jpeg"; - else if (EQ (type, Qpng)) - imageType = @"public.png"; - else if (EQ (type, Qgif)) - imageType = @"com.compuserve.gif"; - else if (EQ (type, Qtiff)) - imageType = @"public.tiff"; -#ifndef HAVE_RSVG - else if (EQ (type, Qsvg)) - imageType = @"public.svg-image"; -#endif -#ifndef HAVE_WEBP - else if (EQ (type, Qwebp)) - imageType = @"org.webmproject.webp"; -#endif - else if (EQ (type, Qheic)) - imageType = @"public.heic"; - - /* NSImage also supports a host of other types such as PDF and BMP, - but we don't yet support these in image.c. */ - - types = [NSImage imageTypes]; -#else /* Work out the image type. */ if (EQ (type, Qjpeg)) imageType = @"jpeg"; @@ -104,7 +126,6 @@ imageType = @"tiff"; types = [NSImage imageFileTypes]; -#endif /* Check if the type is supported on this system. */ if ([types indexOfObject:imageType] != NSNotFound) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 12 02:25:02 2025 Received: (at 79023) by debbugs.gnu.org; 12 Aug 2025 06:25:02 +0000 Received: from localhost ([127.0.0.1]:51354 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uliRR-00087Z-AJ for submit@debbugs.gnu.org; Tue, 12 Aug 2025 02:25:02 -0400 Received: from fhigh-a5-smtp.messagingengine.com ([103.168.172.156]:38829) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uliRN-000877-Nx for 79023@debbugs.gnu.org; Tue, 12 Aug 2025 02:24:58 -0400 Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfhigh.phl.internal (Postfix) with ESMTP id 1450A1400169; Tue, 12 Aug 2025 02:24:52 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Tue, 12 Aug 2025 02:24:52 -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=fm1; t=1754979892; x=1755066292; bh=da4S+x80L0 TxNxAB/SdyLm48uyb4EoTs3jqVmPNvPM8=; b=OBNW24DtElXS2KybLQX718Ly5m xzl8lppGC5LSvPB903IKGSu6qZMrSR3jR/IuyT/dIMeKZc/PR8fV47Raq+LV0R5z pmzVkDCHcHVhgIxlXlODJRtO4BXE5yXjM5xyIlm+MX/n7MmLg24sWnmfqh/fSkm5 SBj36q4vxDdiqosatqVW8/FEeRQA6WpDcfjq0JdITSKZ9dtl9/9snsOJAZ1Ha+l6 2ufmxHLklk68ts2fAxqzZ2zshjz+cNRjpIccJQISKiq+4PfNx8S3cqKXhyrMUr04 bFxGDS2/VNTjJNBkSNhcxYVHzSo9rdc0NaquN72lqsK9Bkap61zzGUMsdVzA== 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=fm3; t= 1754979892; x=1755066292; bh=da4S+x80L0TxNxAB/SdyLm48uyb4EoTs3jq VmPNvPM8=; b=K1896d8SU8wLS3FUyZsVmdLXplbfuU1sZfqgyKYYqAz2mn/IIWS TbSYPUTnICS023CstUL5tesbMrSPhJ5/aYTg/kxhKKtHPc5PqmXsdgzZvfzpKwTX X+SFsAkQK3UXzCUROCrpbwSl0Ykw1OpBd7RwajPdN3R6toUN3UT1rUrowa+Vm+yP ipGIZsgxBuXfCikwdZ6uc2gXAAafv7/raMGc2vJ5NEAD0YYiL7ozAvMcSrkqDPQD 8RA6Zq6kSwuqxBVBhMIgaH75ZTGt8MZBhcpix9RyTOpc1ETZ5apcLOjwZo4VWaps uUPkXHUyuDY4QK2UXqMfzV3WPPgVj5U6x7Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgddufeegieduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpefhvfevufgjfhffkfggtgesmhdtreertd dtjeenucfhrhhomheprfhriigvmhihshhlrgifucetlhgvgigrnhguvghrucfmrghmihnk shhkihcuoegrlhgvgigrnhguvghrsehkrghmihhnshhkihdrshgvqeenucggtffrrghtth gvrhhnpedutdeuudegvdfhiefgteelhedtueeftdegvdefteeuhfekheelieegheejtdet feenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlh gvgigrnhguvghrsehkrghmihhnshhkihdrshgvpdhnsggprhgtphhtthhopeegpdhmohgu vgepshhmthhpohhuthdprhgtphhtthhopeejledtvdefseguvggssghughhsrdhgnhhurd horhhgpdhrtghpthhtoheprhhuugholhhfsegruggrmhhkohhvihgtrdhorhhgpdhrtghp thhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtohepuhhlthhrohhnohesghhmrg hilhdrtghomh X-ME-Proxy: Feedback-ID: i282146b2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 12 Aug 2025 02:24:50 -0400 (EDT) From: =?utf-8?Q?Przemys=C5=82aw_Alexander_Kami=C5=84ski?= To: "Paul D. Nelson" Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) In-Reply-To: References: Date: Tue, 12 Aug 2025 08:24:49 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79023 Cc: rudolf@adamkovic.org, eliz@gnu.org, 79023@debbugs.gnu.org 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 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 12, 2025 at 06:46:38 (+0200), Paul D. Nelson wrote: > Przemys=C5=82aw Alexander Kami=C5=84ski writes: > >> I'm attaching 6 patches (for easy review/scrutiny/integration). >> Those patches that I marked as tested was used by me for >1 week. > > I tried applying the patches for testing, but there were some clashes, > e.g., nullify_frame.patch and misc_releases.patch both the modify the > end of dealloc in nsterm.m, but the modifications do not stack. Yes, that's on purpose. I didn't want them to be considered together. It's also easier for me to manage through Jujutsu front as merge commit is regenerated after patch commit was changed. I'm attaching combined patch for convenience. It already includes ns_native_api_dict_0002.patch (0001 was crashing compilation subprocesses). Best, Przemys=C5=82aw Alexander Kami=C5=84ski --=20 Pointers are real. They=E2=80=99re what the hardware understands. Somebody = has to deal with them. You can=E2=80=99t just place a LISP book on top of an x86 chip and hope that the hardware learns about lambda calculus by osmosis. -- James Mickens "The Night Watch" --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=combined_0001.patch diff --git a/src/macfont.m b/src/macfont.m index 2a0b9aa255..cef4cf80ff 100644 --- a/src/macfont.m +++ b/src/macfont.m @@ -1152,10 +1152,11 @@ CTFontDescriptorCopyAttribute (desc, kCTFontFamilyNameAttribute); CFRelease (desc); } - macfont_set_family_cache (symbol, result); + CFRelease (pat_desc); } - + /* It's possible that we don't have have kCTFontFamilyNameAttribute for symbol, but still cache result */ + macfont_set_family_cache (symbol, result); return result; } diff --git a/src/nsimage.m b/src/nsimage.m index 8f1653d085..d96aeab7b3 100644 --- a/src/nsimage.m +++ b/src/nsimage.m @@ -28,6 +28,7 @@ /* This should be the first include, as it may set up #defines affecting interpretation of even the system includes. */ #include +#include #include "lisp.h" #include "dispextern.h" @@ -56,9 +57,57 @@ ========================================================================== */ +static CFDictionaryRef image_api_dict; + +/* + ns_image_init initializes native support image type cache-dict for + ns_can_use_native_image_api. Needs to be initialized ad-hoc since it's + possible that non-GUI subprocesses will use it. + + Without the cache-dict hundreds of thousands of small, persistent + NSString allocations are happening causing leak 40-60KiB leak per usage. +*/ + +static void ns_image_init (void) +{ + /* NSImage also supports a host of other types such as PDF and BMP, + but we don't yet support these in image.c. */ + NSArray *imageTypes = [NSImage imageTypes]; + Lisp_Object keys[] = { Qnative_image, Qjpeg, Qpng, Qgif, Qtiff, +#ifndef HAVE_RSVG + Qsvg, +#endif +#ifndef HAVE_WEBP + Qwebp, +#endif + Qheic }; + bool values[] = { + YES, + [imageTypes containsObject:@"public.jpeg"], + [imageTypes containsObject:@"public.png"], + [imageTypes containsObject:@"com.compuserve.gif"], + [imageTypes containsObject:@"public.tiff"], +#ifndef HAVE_RSVG + [imageTypes containsObject:@"public.svg-image"], +#endif +#ifndef HAVE_WEBP + [imageTypes containsObject:@"org.webmproject.webp"], +#endif + [imageTypes containsObject:@"public.heic"], + }; + image_api_dict + = CFDictionaryCreate (NULL, (void *) keys, (void *) values, 50, + NULL, NULL); + image_api_dict = CFRetain (image_api_dict); +} + bool ns_can_use_native_image_api (Lisp_Object type) { +#ifdef NS_IMPL_COCOA + if(!image_api_dict) ns_image_init(); + return (bool) (CFDictionaryGetValue(image_api_dict, type) || NO); +#endif NSString *imageType = @"unknown"; NSArray *types; @@ -67,32 +116,6 @@ if (EQ (type, Qnative_image)) return YES; -#ifdef NS_IMPL_COCOA - /* Work out the UTI of the image type. */ - if (EQ (type, Qjpeg)) - imageType = @"public.jpeg"; - else if (EQ (type, Qpng)) - imageType = @"public.png"; - else if (EQ (type, Qgif)) - imageType = @"com.compuserve.gif"; - else if (EQ (type, Qtiff)) - imageType = @"public.tiff"; -#ifndef HAVE_RSVG - else if (EQ (type, Qsvg)) - imageType = @"public.svg-image"; -#endif -#ifndef HAVE_WEBP - else if (EQ (type, Qwebp)) - imageType = @"org.webmproject.webp"; -#endif - else if (EQ (type, Qheic)) - imageType = @"public.heic"; - - /* NSImage also supports a host of other types such as PDF and BMP, - but we don't yet support these in image.c. */ - - types = [NSImage imageTypes]; -#else /* Work out the image type. */ if (EQ (type, Qjpeg)) imageType = @"jpeg"; @@ -104,7 +127,6 @@ imageType = @"tiff"; types = [NSImage imageFileTypes]; -#endif /* Check if the type is supported on this system. */ if ([types indexOfObject:imageType] != NSNotFound) diff --git a/src/nsterm.m b/src/nsterm.m index b006b4d5dd..5b4fe9317c 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -78,6 +78,25 @@ static EmacsMenu *mainMenu; #endif +static volatile int render_blocked = 0; +INLINE void +block_render (void) +{ + render_blocked++; +} +INLINE bool +render_blocked_p (void) +{ + return render_blocked > 0; +} +INLINE void +unblock_render (void) +{ + render_blocked--; +} + + + /* The last known monitor attributes list. */ static Lisp_Object last_known_monitors; @@ -1637,6 +1656,7 @@ [[view window] close]; [view removeFromSuperview]; + [view release]; xfree (f->output_data.ns); f->output_data.ns = NULL; @@ -4956,8 +4976,9 @@ to ourself, otherwise [NXApp run] will never exit. */ send_appdefined = YES; ns_send_appdefined (-1); - + block_render(); [NSApp run]; + unblock_render(); } nevents = n_emacs_events_pending; @@ -5099,7 +5120,9 @@ block_input (); ns_init_events (&event); + block_render(); [NSApp run]; + unblock_render(); ns_finish_events (); if (nr > 0 && readfds) @@ -6839,6 +6862,15 @@ if (fs_state == FULLSCREEN_BOTH) [nonfs_window release]; + + /* Release layer and menu */ + EmacsLayer *layer = (EmacsLayer *)[self layer]; + [layer release]; + [[self menu] release]; + + /* Don't reuse inner - cleanup isn't robust enough */ + emacsframe = nil; + [super dealloc]; } @@ -9033,7 +9065,6 @@ #if defined (NS_IMPL_COCOA) && MAC_OS_X_VERSION_MIN_REQUIRED >= 101400 CGContextRef context = [(EmacsLayer *)[self layer] getContext]; - CGContextFlush (context); double scale = [[self window] backingScaleFactor]; int bpp = CGBitmapContextGetBitsPerPixel (context) / 8; @@ -9084,7 +9115,7 @@ appears to be safe to call redisplay here. */ - (void)layoutSublayersOfLayer:(CALayer *)layer { - if (!redisplaying_p && FRAME_GARBAGED_P (emacsframe)) + if (!redisplaying_p && FRAME_GARBAGED_P (emacsframe) && !render_blocked_p()) { /* If there is IO going on when redisplay is run here Emacs crashes. I think it's because this code will always be run @@ -9588,8 +9619,9 @@ NSTRACE ("[EmacsWindow dealloc]"); /* We need to release the toolbar ourselves. */ + [[self toolbar] release]; [self setToolbar: nil]; - [[self toolbar] release]; + /* Also the last button press event . */ if (last_drag_event) @@ -10994,7 +11026,6 @@ if (!context) return; - CGContextFlush (context); CGContextRelease (context); context = NULL; --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 12 08:12:08 2025 Received: (at 79023) by debbugs.gnu.org; 12 Aug 2025 12:12:08 +0000 Received: from localhost ([127.0.0.1]:52478 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ulnrM-0005bh-Al for submit@debbugs.gnu.org; Tue, 12 Aug 2025 08:12:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51800) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ulnrI-0005b1-PX for 79023@debbugs.gnu.org; Tue, 12 Aug 2025 08:12:05 -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 1ulnrA-0003Xp-Fq; Tue, 12 Aug 2025 08:11:57 -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=yTjNDXO50nfy6s4zMe869jBICvIRHEtBndadYqZNr2Y=; b=okui9F+v9LO/ND2ZFYhQ U/iixaNpd2YweZEwfRIeCeAcHaNzdUVc2AFA5HT1o3nTX1vWNnYL/lekIF01DjxBEAlYqH2m90QIQ lk237a7bafck6kWc5BcY2EeT2X95BfVxtFLB+h+yP6NWR8a8TrVU5JsUE/TOCFXg1ZS0o4uMkw/NG ddD/Nw/aNyzpdFYODusBVLkBWBWXaGdmX0OX6VnHaWFn+YnzHd4StZSutCX1cz238bc/5bQqUwKhg fIWBioCErjatrsL4pmc4+iNck8ZWGJVasi0Fk8TbPCGv+sn4Y8aDlG67e/4p6wLYz72RVokgFvsQS +WsSCytItqpJNA==; Date: Tue, 12 Aug 2025 15:11:51 +0300 Message-Id: <86frdwage0.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?Przemys=C5=82aw?= Alexander =?utf-8?Q?Kami=C5=84ski?= In-Reply-To: (alexander@kaminski.se) Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) References: <5BA8A8B9-96CB-4823-836B-49CEBED77CEF@kaminski.se> <86ldopk5hq.fsf@gnu.org> <113CE362-63BF-4F13-845C-1DB8F6D8580C@kaminski.se> <86frexk2ds.fsf@gnu.org> <86ms8w9z8f.fsf@gnu.org> <86a54lx53t.fsf@gnu.org> <86bjomaskk.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79023 Cc: rudolf@adamkovic.org, 79023@debbugs.gnu.org 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, 12 Aug 2025 08:04:10 +0200 > > I'm starting to wonder if I shouldn't write documentation about > debugging techniques on MacOS, so more people could help If you do, please propose that as patches to etc/DEBUG, preferably in a separate new section. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 12 10:12:44 2025 Received: (at 79023) by debbugs.gnu.org; 12 Aug 2025 14:12:44 +0000 Received: from localhost ([127.0.0.1]:54122 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ulpk3-0003TO-F0 for submit@debbugs.gnu.org; Tue, 12 Aug 2025 10:12:44 -0400 Received: from fout-a3-smtp.messagingengine.com ([103.168.172.146]:39641) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ulpjz-0003Ss-Qu for 79023@debbugs.gnu.org; Tue, 12 Aug 2025 10:12:40 -0400 Received: from phl-compute-09.internal (phl-compute-09.internal [10.202.2.49]) by mailfout.phl.internal (Postfix) with ESMTP id D3F58EC02BD; Tue, 12 Aug 2025 10:12:33 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-09.internal (MEProxy); Tue, 12 Aug 2025 10:12:33 -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=fm1; t=1755007953; x=1755094353; bh=rP0+AAoU70 +FnwmnHFYaEno6jRZrx02tB0jIPOl5oHQ=; b=UP0BT6hePvKzFr7PQ9F0gAjqDN IkA3gYtj8wRJTkkreAebLx1VLb01+CVAZKJhelZKRnhssXkDBrPwNUCZNgYFsrNC mwrcRh4lEzCyjSk9fPY85b3SipxxCEONQY5aYIOlOA9YakV9PAY30fJ7oEQVXa+Y yKfHtsp+3x8SHkHcWWtrzBGY0YQNXI0CveoEQeEropSgQZIR/kvRepJv6yQWkxco mGVONtDHUkWBLi6k9oLYp6+02G/y6G+iz0HfbkXMP/O1Rf0nfeU9HpMmN1+8e+nl V8B8UWh3I85Awn3fKMMEhrQ1kU0lNPrQjzvInQZeM/9LbSSeY6Z9QU5S5x2w== 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=fm3; t= 1755007953; x=1755094353; bh=rP0+AAoU70+FnwmnHFYaEno6jRZrx02tB0j IPOl5oHQ=; b=evXiQ8VMkTRvuI2MfSlotBVNNEMMW/dJ8ee9f4rFqgXs/JjX/0K eYotcrWt4TpWJ2DAhTGDO6vmEClPe+SvMa5xlOj8SoBe0fznwvVBNyhNxGz4afAb ZY1PELqzrgxzfGLIDEtkVJZpth9mYTQ8ltDskEMbBPmVvZMEKKrQ3ioNu5B/goqB rMMHwqpeCYK6O2iPtv/SXY2GeOzxWdLmE6ZT2YZ0hFJOBfthLCASnnxhlkiowvzs GZ6eHVjAwzH1s30Ng+U0V11h9FzpLGkGwfdLWCaioX8OR7mKhlPmfNAg1o4wSq80 CuX8Y2t2BUYajDWEn8MXoFAbFrmJF/py2Hg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgddufeehheegucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhephffvvefujghffffkgggtsehmtderredttdejnecuhfhrohhmpefrrhiivghmhihs lhgrficutehlvgigrghnuggvrhcumfgrmhhiknhskhhiuceophhriigvmhihshhlrgifse hkrghmihhnshhkihdrshgvqeenucggtffrrghtthgvrhhnpeejhfekvdevieejveetgfef heejgfdttdefvddvvdetueehtdfhveduleehkeelhfenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehprhiivghmhihslhgrfieskhgrmhhinhhs khhirdhsvgdpnhgspghrtghpthhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpth htohepjeeltddvfeesuggvsggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopehruhgu ohhlfhesrggurghmkhhovhhitgdrohhrghdprhgtphhtthhopegvlhhiiiesghhnuhdroh hrgh X-ME-Proxy: Feedback-ID: i08494404:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 12 Aug 2025 10:12:32 -0400 (EDT) From: =?utf-8?Q?Przemys=C5=82aw?= Alexander =?utf-8?Q?Kami=C5=84ski?= To: Eli Zaretskii Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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> <86ms8w9z8f.fsf@gnu.org> <86a54lx53t.fsf@gnu.org> <86bjomaskk.fsf@gnu.org> Date: Tue, 12 Aug 2025 16:12:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79023 Cc: rudolf@adamkovic.org, 79023@debbugs.gnu.org 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 (-) --=-=-= Content-Type: text/plain - ns_native_api dictionary update, hopefully final - macfont_list_cache_0001.patch adds a spec-to-list cache - I noticed that it still is leaking (probably with packages that are running results in a subprocess) --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=macfont_list_cache_0001.patch diff --git a/src/macfont.m b/src/macfont.m index 2a0b9aa255..d33c7992ca 100644 --- a/src/macfont.m +++ b/src/macfont.m @@ -2272,7 +2272,7 @@ } static Lisp_Object -macfont_list (struct frame *f, Lisp_Object spec) +macfont_list_impl (struct frame *f, Lisp_Object spec) { Lisp_Object val = Qnil, family, extra; int i, n; @@ -2589,8 +2589,33 @@ unblock_input (); return val; + } + + +static CFMutableDictionaryRef macfont_list_cache; + +static Lisp_Object +macfont_list (struct frame *f, Lisp_Object spec) +{ + if (!macfont_list_cache) { + macfont_list_cache + = CFDictionaryCreateMutable (NULL, 500, NULL, NULL); + CFRetain(macfont_list_cache); + } + + Lisp_Object result; + if (CFDictionaryGetValueIfPresent (macfont_list_cache, spec, + (void *) &result)) + { + return result; + } + + result = macfont_list_impl (f, spec); + CFDictionaryAddValue (macfont_list_cache, copy_font_spec(spec), result); + return result; } + static Lisp_Object macfont_match (struct frame * frame, Lisp_Object spec) { --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=ns_native_api_dict_0003.patch diff --git a/src/nsimage.m b/src/nsimage.m index 8f1653d085..e4493994d1 100644 --- a/src/nsimage.m +++ b/src/nsimage.m @@ -56,9 +56,63 @@ ========================================================================== */ +static CFDictionaryRef image_api_dict; + +/* + ns_image_init initializes native support image type cache-dict for + ns_can_use_native_image_api. Needs to be initialized ad-hoc since it's + possible that non-GUI subprocesses will use it. + + Without the cache-dict hundreds of thousands of small, persistent + NSString allocations are happening causing leak 40-60KiB leak per usage. +*/ + +static void ns_image_init (void) +{ + /* NSImage also supports a host of other types such as PDF and BMP, + but we don't yet support these in image.c. */ + NSArray *imageTypes = [NSImage imageTypes]; + Lisp_Object keys[] = { Qnative_image, Qjpeg, Qpng, Qgif, Qtiff, +#ifndef HAVE_RSVG + Qsvg, +#endif +#ifndef HAVE_WEBP + Qwebp, +#endif + Qheic }; + bool values[] = { + YES, + [imageTypes containsObject:@"public.jpeg"], + [imageTypes containsObject:@"public.png"], + [imageTypes containsObject:@"com.compuserve.gif"], + [imageTypes containsObject:@"public.tiff"], +#ifndef HAVE_RSVG + [imageTypes containsObject:@"public.svg-image"], +#endif +#ifndef HAVE_WEBP + [imageTypes containsObject:@"org.webmproject.webp"], +#endif + [imageTypes containsObject:@"public.heic"], + }; + image_api_dict + = CFDictionaryCreate (NULL, (void *) keys, (void *) values, 50, + NULL, NULL); + CFRetain (image_api_dict); +} + bool ns_can_use_native_image_api (Lisp_Object type) { +#ifdef NS_IMPL_COCOA + if (!image_api_dict) + ns_image_init (); + + bool found; + CFDictionaryGetValueIfPresent (image_api_dict, type, + (void *) &found); + return found; + +#endif NSString *imageType = @"unknown"; NSArray *types; @@ -67,32 +121,6 @@ if (EQ (type, Qnative_image)) return YES; -#ifdef NS_IMPL_COCOA - /* Work out the UTI of the image type. */ - if (EQ (type, Qjpeg)) - imageType = @"public.jpeg"; - else if (EQ (type, Qpng)) - imageType = @"public.png"; - else if (EQ (type, Qgif)) - imageType = @"com.compuserve.gif"; - else if (EQ (type, Qtiff)) - imageType = @"public.tiff"; -#ifndef HAVE_RSVG - else if (EQ (type, Qsvg)) - imageType = @"public.svg-image"; -#endif -#ifndef HAVE_WEBP - else if (EQ (type, Qwebp)) - imageType = @"org.webmproject.webp"; -#endif - else if (EQ (type, Qheic)) - imageType = @"public.heic"; - - /* NSImage also supports a host of other types such as PDF and BMP, - but we don't yet support these in image.c. */ - - types = [NSImage imageTypes]; -#else /* Work out the image type. */ if (EQ (type, Qjpeg)) imageType = @"jpeg"; @@ -104,7 +132,6 @@ imageType = @"tiff"; types = [NSImage imageFileTypes]; -#endif /* Check if the type is supported on this system. */ if ([types indexOfObject:imageType] != NSNotFound) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Best, Przemys=C5=82aw Alexander Kami=C5=84ski --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 27 04:07:32 2025 Received: (at 79023) by debbugs.gnu.org; 27 Aug 2025 08:07:33 +0000 Received: from localhost ([127.0.0.1]:58867 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1urBBs-0000mp-HI for submit@debbugs.gnu.org; Wed, 27 Aug 2025 04:07:32 -0400 Received: from fhigh-b8-smtp.messagingengine.com ([202.12.124.159]:58161) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1urBBp-0000mV-Gy for 79023@debbugs.gnu.org; Wed, 27 Aug 2025 04:07:30 -0400 Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfhigh.stl.internal (Postfix) with ESMTP id 435FD7A0061; Wed, 27 Aug 2025 04:07:22 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Wed, 27 Aug 2025 04:07:22 -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=fm2; t=1756282042; x=1756368442; bh=WL91s66mq/rVjUlApZ5G3XkK/JGTbasJoXYZnFvRAFU=; b= BUtFPIgF46QYvvs3SZpBCOunlFRW2X5FUrQ96rK6f3BVDwiuvdiW3Jmq9SEyumrc RkauFbQUR/14RY4+ZANAzfZAJkzdKavUKbfGjgJciqE5RQ88VP/5FRtBwzHQ/Z6z S84nfHs7aNQQ7H+j80EBQHZ3DK7i8av8knMlonkYQEhnpJ+6cdDey+dZ6boY/UZX Msr7sALD0y+GLm/NqWAvn+prCfKhvxiAHdi/ZzWT3DVgGkX/YtTVn7r8m4V0GKlx /5iJs2v554kaI1+XMgrwXmm+LFK0+Gbc8HhRAoULNk19kOfLZN5iSjZUguMjzrIE v8LosyduChFFONGsS8Q76A== 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=fm1; t=1756282042; x= 1756368442; bh=WL91s66mq/rVjUlApZ5G3XkK/JGTbasJoXYZnFvRAFU=; b=N 3faAQdWhu1Vc+oT/2lE6Ss0BiupOptwWJfiHtXpsiSkZbdPuGFHOKK3WiMUOvIS5 88ZDitzbRYGB4AeVVTWteZJJlDhjtX4qvSzYwhzejC3P1ck/VTI1rjeiGwhOaYzt rwBYmzIQcEtPyBAuVxJ7duwb8DEstCgPnk+hIGqAqEO5NMtpMLZ0RNTx/hcCYeKb nfTjmUsL0eYyLQRY4HU98pTzIJtA9rWU/Mv34pg0sLlrlb38ucaZQrm6qNB8IgHx ojAFZyrLOhINACvz9FIcJbHJupiiYFGwfawWUiWecFTw1bsyWuH6peBMuusVLT3k G8wNN8+nlE+CSHP7NA4MQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgddujeejieefucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhephffvvefujghffffkgggtgfesthhqredttddtjeenucfhrhhomheprfhriigvmhih shhlrgifucetlhgvgigrnhguvghrucfmrghmihnkshhkihcuoegrlhgvgigrnhguvghrse hkrghmihhnshhkihdrshgvqeenucggtffrrghtthgvrhhnpedvveelveeltdelledtledu tedtleetffekhedtgfeivedvtdevleevfffhkeejvdenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhgvgigrnhguvghrsehkrghmihhnshhk ihdrshgvpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpohhuthdprhgtphhtth hopeejledtvdefseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtoheprhhuugho lhhfsegruggrmhhkohhvihgtrdhorhhgpdhrtghpthhtohepvghlihiisehgnhhurdhorh hg X-ME-Proxy: Feedback-ID: i282146b2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 27 Aug 2025 04:07:20 -0400 (EDT) From: =?utf-8?Q?Przemys=C5=82aw_Alexander_Kami=C5=84ski?= To: Eli Zaretskii Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) 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> <86ms8w9z8f.fsf@gnu.org> <86a54lx53t.fsf@gnu.org> <86bjomaskk.fsf@gnu.org> Date: Wed, 27 Aug 2025 10:07:19 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79023 Cc: rudolf@adamkovic.org, 79023@debbugs.gnu.org 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 (-) Eli, should I maybe break off those 6 patches and submit them to emacs-devel for easier integration? Best, Przemys=C5=82aw Alexander Kami=C5=84ski From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 27 08:35:34 2025 Received: (at 79023) by debbugs.gnu.org; 27 Aug 2025 12:35:34 +0000 Received: from localhost ([127.0.0.1]:59992 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1urFNG-0002uK-2C for submit@debbugs.gnu.org; Wed, 27 Aug 2025 08:35:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36570) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1urFN8-0002tn-Uv for 79023@debbugs.gnu.org; Wed, 27 Aug 2025 08:35:27 -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 1urFMy-0006Xd-Fk; Wed, 27 Aug 2025 08:35: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=+g4mWcZeql1TEUx7hZVEbow+KDgW5RiGx8f5HoawX1g=; b=QiW53LnlolpQbjusZGuE Q2i74zSDp5Nylpv0BOfElJCsaLWKBsiuYjquvqpSkx8OAgcXq1IkxBoFM/RrBkwcRHpQvS3JwCaMT V0IUkhvr+GXNczLIrfYODqiVmJbVomaMWRxVnNlYBUJmNa0PjS4zJQr8q4GlzkGQgJUQ2LDO8ttFn zj1xwgjlFeQNCcnsZawuzHb+o8dTu1U6o8Tc9escOWMgeBgcDu1eAZ8OCCCmjZ8uYzGlXKM62LKab F0gae2fLd46NWYNmZO8ER8B6Z2GN9yNNq4YykIvL+k91L2DdDzy47OT+rvDWBzr4iYrcVLyDIYLct SVlsdQ8Y9j5WGQ==; Date: Wed, 27 Aug 2025 15:35:07 +0300 Message-Id: <86o6s1t01w.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?Przemys=C5=82aw?= Alexander =?utf-8?Q?Kami=C5=84ski?= , Alan Third , =?utf-8?Q?Gerd_M=C3=B6llmann?= In-Reply-To: (alexander@kaminski.se) Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) References: <5BA8A8B9-96CB-4823-836B-49CEBED77CEF@kaminski.se> <86ldopk5hq.fsf@gnu.org> <113CE362-63BF-4F13-845C-1DB8F6D8580C@kaminski.se> <86frexk2ds.fsf@gnu.org> <86ms8w9z8f.fsf@gnu.org> <86a54lx53t.fsf@gnu.org> <86bjomaskk.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79023 Cc: rudolf@adamkovic.org, 79023@debbugs.gnu.org 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: rudolf@adamkovic.org, 79023@debbugs.gnu.org > Date: Wed, 27 Aug 2025 10:07:19 +0200 > > Eli, > > should I maybe break off those 6 patches and submit them to emacs-devel > for easier integration? No, we should ask relevant people (CC'ed) to please review the patches and comment on them. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 27 08:53:10 2025 Received: (at 79023) by debbugs.gnu.org; 27 Aug 2025 12:53:10 +0000 Received: from localhost ([127.0.0.1]:60067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1urFeI-0003ip-1J for submit@debbugs.gnu.org; Wed, 27 Aug 2025 08:53:10 -0400 Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]:54660) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1urFeA-0003i4-QV for 79023@debbugs.gnu.org; Wed, 27 Aug 2025 08:53:07 -0400 Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-45a1b05ac1eso36267255e9.1 for <79023@debbugs.gnu.org>; Wed, 27 Aug 2025 05:53:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756299176; x=1756903976; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=BkC7ALmtoDOgnjHY2P7VFgEFPopJbyYLw3JCw/9Mctw=; b=kR9vpQDuXUEl5eKLAzEKMNyMM27F/U5sXgn3ju9Yb32VqkwNKcMSa53uzpTngZkezq p1axb2srsczSqO3vNeSNV6CHa+wyHq0x2ULFsOEq/FmrINm5IkOLJup4ZQmQk5+hZyNI 72/K9Sn+BFDpXutqS40TXq3DucwlXL6+U6FxSLWcXZHQumEu2QD+66es0AdwE3G1BCNQ Wkrqt1nq2C6O9pkhteKNO7uunFZ8qoFoDZqN6G3DcNQNtAQr+wgXctMJ6mJqGsTUbAmb UYUkRx2HU+20VS4AV4tV8E8FZIG6e/fD+vVHwJRrEUgEK/ZL5sljiXVUn/mHFDdPIUdp Am/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756299176; x=1756903976; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=BkC7ALmtoDOgnjHY2P7VFgEFPopJbyYLw3JCw/9Mctw=; b=D2IzZbPLJP4FpWgg3RFBWH8lmZkz/+IT6u3aK9FiTzw86NCeOWEjXeecTeW1+6sBZe N4Akgz7kYRqyY0Xq7sCVKoVfXJRmkIfaWmWuX2N6GD3gM2DQS+h0kuNP7r8KzVfpZE27 stQnWVWAJX+oSWj+OmxacdEhCkbeI86fgg1Uy9pi7sYKTpeY2LXy33Rim+7wEsHHfmpl 6iKyHjE8zTTqh6pu1dgIDhulcRxYQImYsXWa6yGbzv9HtR8Baligb5TXkhxBodr4BTgy xEfWgKkZl6njyU4XOtDjlHRl+RI0XVydvEwuqdlRpcE7rjkSEZwq0AbPCilFJVWezwDP 9udw== X-Forwarded-Encrypted: i=1; AJvYcCU4m/AElGAa6XLkSTpRfrMr70O3p2nD4mdrsKeDI64OlCYej9kSZ5+eJ0RAukqvcTk8H0JypA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YydLRIcjE12gmoY+QdELey8y+kgZKXH7bon3FjTzKZgEhsWl5rb 0gdfkLVD5vCZKSIeLuYr41CrhK8sCmGbsUGJekrC9X0ujJR9aq1+RdmisGynsSdv X-Gm-Gg: ASbGncugrdp3HHS4YAKlt+aE+wxh/tw/z0uIl6R/Ct2JRJ7qQxkjiCYPb0zn3/Ha/a1 IM9GYxdcyN53RXFCVZlUjLvOOeJapPvveKu/T6B1yEG4QknCvbGm+IV71VjOIuXDRVpWFSs/8T/ UQt/PpIf+S6Ce8eS+skOFM7aORmrw5dg3E9Q1fU2EGpwGq8XCa4HevbiHQSTIHXYmfSWfD6TYuI 3XLvRicMLJrjr5vPunWg0SVJCVZzHGTkbrl4opSvar5QQmuc7oXo91Zc2mZXgNYRMg+X0K2S7Jx 4xFi95g5/2smNtZlULopq9d991vm2PFUpWFmPx44C4YD3iw9iAY1spClOlGwhbluGvfmBsybOxR CL9DDFPk4atxl7Y0l8VyLv9PVGYu/yJaLWvXusMtTyJL2bdp1ks5aP6JIDsLmAPW562Mzv+piGm H0PrSPg33uzSWD+JB5kDWd/hfkDt1FdwiKtmT8nPqg X-Google-Smtp-Source: AGHT+IE+TF6IRXJKnYBZnPZr7ZUEl5jNG3dM9DFd4eMutZxgbBZfeHbwtZstUzm5E9/9WX27AIoz6Q== X-Received: by 2002:a05:600c:4450:b0:45b:74fc:d6ec with SMTP id 5b1f17b1804b1-45b74fcd8a2mr4002165e9.8.1756299175604; Wed, 27 Aug 2025 05:52:55 -0700 (PDT) Received: from pro2 (p200300e0b7061500bd140ed3e26ea2ce.dip0.t-ipconnect.de. [2003:e0:b706:1500:bd14:ed3:e26e:a2ce]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3ccecb9a608sm2057019f8f.55.2025.08.27.05.52.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Aug 2025 05:52:55 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) In-Reply-To: <86o6s1t01w.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> <86ms8w9z8f.fsf@gnu.org> <86a54lx53t.fsf@gnu.org> <86bjomaskk.fsf@gnu.org> <86o6s1t01w.fsf@gnu.org> Date: Wed, 27 Aug 2025 14:52:53 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79023 Cc: =?utf-8?Q?Przemys=C5=82aw?= Alexander =?utf-8?Q?Kami=C5=84ski?= , rudolf@adamkovic.org, Alan Third , 79023@debbugs.gnu.org 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 (-) Eli Zaretskii writes: >> From: Przemys=C5=82aw Alexander Kami=C5=84ski >> >> Cc: rudolf@adamkovic.org, 79023@debbugs.gnu.org >> Date: Wed, 27 Aug 2025 10:07:19 +0200 >>=20 >> Eli, >>=20 >> should I maybe break off those 6 patches and submit them to emacs-devel >> for easier integration? > > No, we should ask relevant people (CC'ed) to please review the patches > and comment on them. Sorry, but I'll have to pass. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 31 15:46:18 2025 Received: (at 79023) by debbugs.gnu.org; 31 Aug 2025 19:46:18 +0000 Received: from localhost ([127.0.0.1]:55379 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uso0I-0000Pl-4a for submit@debbugs.gnu.org; Sun, 31 Aug 2025 15:46:18 -0400 Received: from dane.soverin.net ([2a10:de80:1:4091:b9e9:2229:0:1]:56699) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uso0E-0000PP-03 for 79023@debbugs.gnu.org; Sun, 31 Aug 2025 15:46:16 -0400 Received: from smtp.soverin.net (unknown [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 4cFMv151pyz1D3v; Sun, 31 Aug 2025 19:46:05 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net (Postfix) with ESMTPSA id 4cFMv10Tkbz38; Sun, 31 Aug 2025 19:46:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1756669565; bh=vw//FtnIcTS9VRV4kWbBXaPRzFt9YXwzrwMp8osJfd0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=IyXBdMdmuSOjLQbpqDeZcHDFcB7QebNEtZiB18/Szs5WtvusmNn7unCe4/GItpw7E VFZ1mlMLt8/J792/6CYjZp7vC9Rz0UkjPF7F5Ty0MZaVbvcykcF4rMaAVV34A8U3gf Cs2BCMuRdJb5sJFUkcH61mq0iifpAqJ6M0vK4Y4CmYUjx7Adm2Fa/+ezyYbZApSiTr 9QsNPPZzihfxq36OZVqYA4k+960yLyiTCB5pUKK9b5DOjPfQ4X3862w6RADPsWVqJ7 JU/+mLsBT6krb+dQxT/qlxlMWRNY7DS2MbRFA9f2B/Qd1ME0QvsbXRGrjOVbCDZ80W PA1OXUoz9ol8g== X-CM-Envelope: MS4xfC0Nf737nou2yfAd+gJY85MB+k7f1fIQn3nZGzMjp0HFwDeFVNgDgyfXVT7JWBcsSst6Iat+BENEifRn0l0fcn8pfJT2P9fMqAiWHxLnL0rujlNjGlMY ajfBwY35HtziVHw9RZXvhw5+yCaN1fZEffCfxf5HunbglC/kdkjjrKsZK6hF9R7LUPqTSP5ZfhxRBTpFbtLZaGvWe9wYTKgkCMe3Hwe460IyJkkjQUONQ0og FEZoQ3ytAxMaG4aeBM95I6tkgwk2lXob7wN4gkUE/4hYPPPbwwA3u/TWtT2+RZTS Received: from localhost (faroe.holly.idiocy.org [local]) by faroe.holly.idiocy.org (OpenSMTPD) with ESMTPA id 1a3ed8f4; Sun, 31 Aug 2025 19:46:03 +0000 (UTC) Date: Sun, 31 Aug 2025 20:46:03 +0100 From: Alan Third To: =?utf-8?Q?Przemys=C5=82aw_Alexander_Kami=C5=84ski?= Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) Message-ID: Mail-Followup-To: Alan Third , =?utf-8?Q?Przemys=C5=82aw_Alexander_Kami=C5=84ski?= , Eli Zaretskii , rudolf@adamkovic.org, 79023@debbugs.gnu.org References: <113CE362-63BF-4F13-845C-1DB8F6D8580C@kaminski.se> <86frexk2ds.fsf@gnu.org> <86ms8w9z8f.fsf@gnu.org> <86a54lx53t.fsf@gnu.org> <86bjomaskk.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-Debbugs-Envelope-To: 79023 Cc: rudolf@adamkovic.org, Eli Zaretskii , 79023@debbugs.gnu.org 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 Mon, Aug 11, 2025 at 08:47:44PM +0200, Przemysław Alexander Kamiński wrote: > > I'm attaching 6 patches (for easy review/scrutiny/integration). > Those patches that I marked as tested was used by me for >1 week. > > * render_block_small.patch (significant impact, tested): > > This is similar patch to previous one, but it's minimal. It's crucial > to avoid "blink" redraws. > Still breaks smooth resizing, but frame-resize-pixelwise set to true > makes it unnoticable. I'm not convinced this is the way to do this. I still think a better solution would be to move the redisplay call to the EmacsLayer's 'display' method. As I understand it the system should only call that method when it actually wants to display the output. Is that called too often? > * cache_all_font_results.patch (significant impact, requires testing): > > This one prevents huge leak. I was trying to debug emacs-mac version (which > has very deep traces for allocations, more 256 deep, which is limit for > Instrumentations). > > That led to full malloc logging and discovery that macfont listings were > allocating plenty of font-related data. Some of it it never cleared. > > I didn't test it and worry that caching "null" result might introduce > some bugs, but it was hundreds of megabytes of allocations on -Q instance. I can't comment on this as I have no idea how macfont.m works. Perhaps some of the people working on the Mac port can help. > * dont_flush_cg.patch (medium impact, tested): > > Based on documentation of CGContextFlush it should seldom be used, as > it's much better to give OS possibility to decide when to flush. It > prevents non-needed renders (and allocations etc.) See notes below. > * misc_releases.patch (small-mid impact, tested): > > This one is based on Rudolf Adamkovič patch with some minor extra > releases and adjustments > (like releasing an object before setting it to nil ;)) EmacsLayer is only used on Cocoa, and only on certain versions, so anything that references it needs to be limited. Look at the #if before the definition of EmacsLayer. > * ns_native_api_dict.patch (small-mid impact, needs testing): > > A small leak, but modified function had ~600_000 allocations after very > short test runs. Seems like it wasted a lot of power, so I decided it > should be checking dictionary hydrated at start and queried later > instead of checking during runtime. > > I believe that high NSString allocation amount was indirectly caused by > using autorelease pools. LGTM except for the same problem as above. You'll need to look at the #if or #ifdefs around the code and ensure the new code is correctly excluded when building on GNUstep. I think you also removed a #if but left the associated #else and #endif, although I could be wrong about that. > * nullify_frame.patch (small impact, tested): > > releases reference to a frame, as I've found traces in which resources > were left behind, small leak. This one is funny as emacsframe is a pointer to a "struct frame" and we're not using garbage collection in NS so I don't see how simply having a reference in a released object can prevent that struct from being properly freed. Am I missing something? > + /* Don't reuse inner - cleanup is robust enough */ > + emacsframe = nil; > + And I don't understand the comment. > diff --git a/src/nsterm.m b/src/nsterm.m > index b006b4d5dd..057d876a35 100644 > --- a/src/nsterm.m > +++ b/src/nsterm.m > @@ -9033,7 +9033,6 @@ > > #if defined (NS_IMPL_COCOA) && MAC_OS_X_VERSION_MIN_REQUIRED >= 101400 > CGContextRef context = [(EmacsLayer *)[self layer] getContext]; > - CGContextFlush (context); > > double scale = [[self window] backingScaleFactor]; > int bpp = CGBitmapContextGetBitsPerPixel (context) / 8; Immediately after this flush we access the pixels directly in the buffer, so we *require* that all drawing actions in the context have been completed, otherwise we risk doing actions out of order. Therefore this flush is required. > @@ -10994,7 +10993,6 @@ > if (!context) > return; > > - CGContextFlush (context); > CGContextRelease (context); > context = NULL; This one is probably superfluous as the CGContextRelease will probably do the flush itself, but I don't know that for sure and we definitely need it flushed before we can perform the next action, so I don't see this as a problem. Aside from that I think there was maybe some non-GNU-standard style C in the nsimage patch, but I'm not entirely clear how it should look myself. Thanks! -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 07 11:04:04 2025 Received: (at 79023) by debbugs.gnu.org; 7 Sep 2025 15:04:04 +0000 Received: from localhost ([127.0.0.1]:45011 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uvGvv-0002a4-Ln for submit@debbugs.gnu.org; Sun, 07 Sep 2025 11:04:04 -0400 Received: from fout-a4-smtp.messagingengine.com ([103.168.172.147]:40081) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uvGvr-0002Zf-4q for 79023@debbugs.gnu.org; Sun, 07 Sep 2025 11:03:56 -0400 Received: from phl-compute-09.internal (phl-compute-09.internal [10.202.2.49]) by mailfout.phl.internal (Postfix) with ESMTP id B0F0CEC00E3; Sun, 7 Sep 2025 11:03:43 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-09.internal (MEProxy); Sun, 07 Sep 2025 11:03:43 -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=fm2; t=1757257423; x=1757343823; bh=eNv1T0YramVAEavL7aFH1qQnkA8W/E3fVX2DaBEoqO8=; b= lTPMDyr4F3OFmGQnTQH0nEmPPcjiYRLwhjhiC40+U7HciPRX6pneGBQkBuyiV16e 04HfockYZfqoS6YHmIuziG0S/FU5Max1WlNT9wop+QlW11dD6muvhZqBxXN01lw7 K+AB4dUHaPLp7WKkKOPnproj9M/vmC2Mh96i9PhX4sI9moGEydmS47kMpuTU1spa +gTECRKLtTZC1+J3rkIzwmqVIVmoANMa3M97sUAkl5IvBXdIH9DXphpiTnBpPClC uEeDtxMQcwxyImKiUXEy4J/J5apbcQpUWiN0IXjPT324ZuLU4x3eAHP//V1GILX/ DrfrqY0ysR4IxQqcSCKy4w== 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=fm1; t=1757257423; x= 1757343823; bh=eNv1T0YramVAEavL7aFH1qQnkA8W/E3fVX2DaBEoqO8=; b=U SbNEpPw8+8XzdwkYCFPnjdTGSEw9XDSsV5YD3HqNUZ9AubGILDMgqBZeK5w3Whzg FNDR1cgk+bvJPJtmhlaV8dxJJzlGjtoYzgqS1S3AJQvtXho9RmFqhStOCrr1IwIF pEDy+OTbuSRiOxLucpEsalM2RdrIVskMPGD8F4hLa+l4LBIy4bqKr/J1CeLU1O9b X/dYTPVjsCW63rk6iM/didV46zwJ7CbzJpe42U+hyYZ+65BBnVyjZkM+mQASyKau jJ+/8bh1FjIBjiosMmh5rYLmD2UdvABCQX1WET2lSLaexa2YUuKm6/X8lAQvEpgi Vh5NvPRIZxVh8lPPDiGkA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddugeeliecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufgjfhffkfggtgfgsehtqhertddttdejnecuhfhrohhmpefrrhiivghmhihs lhgrficutehlvgigrghnuggvrhcumfgrmhhiknhskhhiuceorghlvgigrghnuggvrheskh grmhhinhhskhhirdhsvgeqnecuggftrfgrthhtvghrnhepvdevleevledtleeltdeludet tdelteffkeehtdfgieevvddtveelveffhfekjedvnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomheprghlvgigrghnuggvrheskhgrmhhinhhskhhi rdhsvgdpnhgspghrtghpthhtohepgedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoh epjeeltddvfeesuggvsggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopehruhguohhl fhesrggurghmkhhovhhitgdrohhrghdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrgh dprhgtphhtthhopegrlhgrnhesihguihhotgihrdhorhhg X-ME-Proxy: Feedback-ID: i282146b2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 7 Sep 2025 11:03:42 -0400 (EDT) From: =?utf-8?Q?Przemys=C5=82aw_Alexander_Kami=C5=84ski?= To: Alan Third Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) In-Reply-To: References: <113CE362-63BF-4F13-845C-1DB8F6D8580C@kaminski.se> <86frexk2ds.fsf@gnu.org> <86ms8w9z8f.fsf@gnu.org> <86a54lx53t.fsf@gnu.org> <86bjomaskk.fsf@gnu.org> Date: Sun, 07 Sep 2025 17:03:38 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79023 Cc: rudolf@adamkovic.org, Eli Zaretskii , 79023@debbugs.gnu.org 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 (-) Hi Alan! On Sun, Aug 31, 2025 at 20:46:03 (+0100), Alan Third wrote: >> * render_block_small.patch (significant impact, tested): >>=20 >> This is similar patch to previous one, but it's minimal. It's crucial >> to avoid "blink" redraws. >> Still breaks smooth resizing, but frame-resize-pixelwise set to true >> makes it unnoticable. I start to hope this patch won't have to be implemented. If there are no allocations (or allocations are reused) then it doesnt matter how fast they are processed.=20 >> * dont_flush_cg.patch (medium impact, tested): >>=20 >> Based on documentation of CGContextFlush it should seldom be used, as >> it's much better to give OS possibility to decide when to flush. It >> prevents non-needed renders (and allocations etc.) > > See notes below. > >> * misc_releases.patch (small-mid impact, tested): >>=20 >> This one is based on Rudolf Adamkovi=C4=8D patch with some minor extra >> releases and adjustments >> (like releasing an object before setting it to nil ;)) > > EmacsLayer is only used on Cocoa, and only on certain versions, so > anything that references it needs to be limited. Look at the #if > before the definition of EmacsLayer. Will look into this, but I started wondering about breaking of Cocoa code outside. Going through nsterm.m is quite confusing. >> * ns_native_api_dict.patch (small-mid impact, needs testing): >> ... > LGTM except for the same problem as above. You'll need to look at the > #if or #ifdefs around the code and ensure the new code is correctly > excluded when building on GNUstep. > > I think you also removed a #if but left the associated #else and > #endif, although I could be wrong about that. Same. >> * nullify_frame.patch (small impact, tested): >>=20 >> releases reference to a frame, as I've found traces in which resources >> were left behind, small leak. > > This one is funny as emacsframe is a pointer to a "struct frame" and > we're not using garbage collection in NS so I don't see how simply > having a reference in a released object can prevent that struct from > being properly freed. Am I missing something? > >> + /* Don't reuse inner - cleanup is robust enough */ >> + emacsframe =3D nil; >> + > And I don't understand the comment. I patched this comment. It should be "cleanup isn't robust enough". Releasing emacsframe reference seems to release these - otherwise there are still objects that are referencing it. >> diff --git a/src/nsterm.m b/src/nsterm.m >> index b006b4d5dd..057d876a35 100644 >> --- a/src/nsterm.m >> +++ b/src/nsterm.m >> @@ -9033,7 +9033,6 @@ >>=20 >> #if defined (NS_IMPL_COCOA) && MAC_OS_X_VERSION_MIN_REQUIRED >=3D 101400 >> CGContextRef context =3D [(EmacsLayer *)[self layer] getContext]; >> - CGContextFlush (context); >>=20 >> double scale =3D [[self window] backingScaleFactor]; >> int bpp =3D CGBitmapContextGetBitsPerPixel (context) / 8; > > Immediately after this flush we access the pixels directly in the > buffer, so we *require* that all drawing actions in the context have > been completed, otherwise we risk doing actions out of order. > Therefore this flush is required. For context - I'm running this pretty much for couple weeks, and I haven't observed any issues. The flush is going to be happening every frame anyways, with it the flush count happens thousands of times. But, truth be told, I haven't ran graphic heavy workflows (like images, PDFs, etc.) so it might require more testing in that particular area. Also I really hope that this could be prevented at all. The problem isn't memory usage per se, but how allocations are happening. If allocations can be put in arenas/zones than none of it actually matters. > Aside from that I think there was maybe some non-GNU-standard style C > in the nsimage patch, but I'm not entirely clear how it should look > myself. Thanks for bringing this to my attention. I'll look into this, but I'm at some... other level right now ;) (isolated builds and quick clean rebuilds, as this kicked me in the back couple times already). Best, Przemys=C5=82aw Alexander Kami=C5=84ski --=20 Pointers are real. They=E2=80=99re what the hardware understands. Somebody = has to deal with them. You can=E2=80=99t just place a LISP book on top of an x86 chip and hope that the hardware learns about lambda calculus by osmosis. -- James Mickens "The Night Watch" From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 19 04:43:14 2025 Received: (at 79023) by debbugs.gnu.org; 19 Sep 2025 08:43:15 +0000 Received: from localhost ([127.0.0.1]:36922 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uzWi0-00009F-6Y for submit@debbugs.gnu.org; Fri, 19 Sep 2025 04:43:14 -0400 Received: from dane.soverin.net ([185.233.34.148]:45183) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uzWhu-00006n-OA for 79023@debbugs.gnu.org; Fri, 19 Sep 2025 04:43:08 -0400 Received: from smtp.soverin.net (unknown [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 4cSmH71sgdzPd; Fri, 19 Sep 2025 08:42:59 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net (Postfix) with ESMTPSA id 4cSmH65ghxz1P; Fri, 19 Sep 2025 08:42:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1758271379; bh=lADO/w2aH455KNXT1hmAY+xsrtNQQGvJKhRT8KSAK2A=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PlNfAcCmieewAu5SmSD4T6VlyUKPJRj0bodBLSmTx3ZZuRpZLP+47CVM7ykSL/xyC AAs79fi3zmAbLRencSTRBA1ZfGvf2QQQopwcT67+GxF7qqBxA86Yab/X1X9/2stuPi WuKxAVL8aCQTomUYFZffHf/WyOetjAAq0Z9F3EDklcer84gJx+5A+PHSqk2DlpzPO/ hKf8Mq5i7MXbm/lRx2y3oIir9XBQOsz/tJ+DgpmSSu0FKFqGzHBntS+g3eLSyEEQN9 u4V41cA1y04LMYdYhNcEqDNFOzWCooxZDwSbZcVLfPmLIAvJpbLLP+gRS/cdFKF2gP WMSJoDlj/TrtQ== X-CM-Envelope: MS4xfFodgyi3WyJGA88z6eRI3WQIj1jlTZ/JrPR6l3uxh7bKFN4dVTNmRW4lODOUnDnkAj8ZALdYt1YlbdeGARAbH6u4L7uzE3S49ngl/rITbPuJiPXLIT0o 0XbwKRMe0oedrh2fOgR9wvsC0aBfqfxeBxculPxKcCMx9BUOWHgHiLykfZTagLyS0pQ95dxQhjP+yJttfNG4HIY/TmTgOYgGcu4/DKV58pMfIQQZYjqNdTga U7udbFN9b4DWH8KyV2prmlZkg6vMCcRDU4UNscEjc4UoJrzl82uO2LNicsCwU7z3 Received: from localhost (shetland.holly.idiocy.org [local]) by shetland.holly.idiocy.org (OpenSMTPD) with ESMTPA id 580dc4c9; Fri, 19 Sep 2025 08:42:57 +0000 (UTC) Date: Fri, 19 Sep 2025 09:42:57 +0100 From: Alan Third To: =?utf-8?Q?Przemys=C5=82aw_Alexander_Kami=C5=84ski?= Subject: Re: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS) Message-ID: Mail-Followup-To: Alan Third , =?utf-8?Q?Przemys=C5=82aw_Alexander_Kami=C5=84ski?= , Eli Zaretskii , rudolf@adamkovic.org, 79023@debbugs.gnu.org References: <86ms8w9z8f.fsf@gnu.org> <86a54lx53t.fsf@gnu.org> <86bjomaskk.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.7 (/) X-Debbugs-Envelope-To: 79023 Cc: rudolf@adamkovic.org, Eli Zaretskii , 79023@debbugs.gnu.org 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 Sun, Sep 07, 2025 at 05:03:38PM +0200, Przemysław Alexander Kamiński wrote: > Hi Alan! Hi Alexander, To get this moved on, can you please provide a single patch with all the missed memory releases and we can get that committed to master? I think we all agree they are needed so there's no point in discussing them further. -- Alan Third