From unknown Thu Aug 14 22:14:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#56546: 29.0.50; unbounded RAM comsumption when displaying images Resent-From: "Jose A. Ortega Ruiz" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Jul 2022 01:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 56546 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 56546@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.165776255729242 (code B ref -1); Thu, 14 Jul 2022 01:36:01 +0000 Received: (at submit) by debbugs.gnu.org; 14 Jul 2022 01:35:57 +0000 Received: from localhost ([127.0.0.1]:48045 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oBnlk-0007bW-4z for submit@debbugs.gnu.org; Wed, 13 Jul 2022 21:35:57 -0400 Received: from lists.gnu.org ([209.51.188.17]:38372) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oBnlh-0007bO-Tm for submit@debbugs.gnu.org; Wed, 13 Jul 2022 21:35:54 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56670) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBnlh-0005Vf-Kn for bug-gnu-emacs@gnu.org; Wed, 13 Jul 2022 21:35:53 -0400 Received: from relay1-d.mail.gandi.net ([217.70.183.193]:40585) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBnle-0006Tt-79 for bug-gnu-emacs@gnu.org; Wed, 13 Jul 2022 21:35:53 -0400 Received: (Authenticated sender: mail@jao.io) by mail.gandi.net (Postfix) with ESMTPSA id 3DA6E240004 for ; Thu, 14 Jul 2022 01:35:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jao.io; s=gm1; t=1657762547; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=u+qJzVAWQSR8AKo8PHT7WwoqaEe+tzGSLL9FkbcHW4U=; b=aAq3D2rijlai22xToXoX33qHrAgw0D9rhPIqtfaLWWM/h+VkJpQv0I/7c0oRx43K/jnSXR 72nFp/AdgHuk47xY6Z74QCksRQ4GOyT7VIs92RU1UEnBBmsqpH0etlp+Ky0Ez/K85XxkhG vDXIDurXiUqIz+3wZB+bG44rOwuWWvSJF0kh0pqFw+JNM1wo+R7HJhWX3yCJlWvVUnnsEz x78hjxSf9xn/YHBPzZrtgsQK+lW2Ji5NEqug8KKyiPglcr0wSjCg1jtQnVPz/v0mtV+Y12 q2L5933UUuG1hlhq3s47AmXnHSORhphXRXaOcKv5tY19lV5dLiW2hbZlnALCWg== Received: from localhost (rivendell.localdomain [local]) by rivendell.localdomain (OpenSMTPD) with ESMTPA id 18d1e70b for ; Thu, 14 Jul 2022 01:35:46 +0000 (UTC) From: "Jose A. Ortega Ruiz" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) X-Attribution: jao X-Clacks-Overhead: GNU Terry Pratchett X-URL: Date: Thu, 14 Jul 2022 02:35:46 +0100 Message-ID: <87cze84gst.fsf@mail.jao.io> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=217.70.183.193; envelope-from=mail@jao.io; helo=relay1-d.mail.gandi.net 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.7 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.7 (--) It seems to be easy to make emacs (under X) to consume more and more RAM, which is never released, by making it display images. A extreme (in my experience) case is animated GIFs, try: - emacs -Q - M-x eww RET https://xenodium.com/emacs-zones-to-lift-you-up/ - RAM consumption grows to ~600Mb - R (redisplay page): RAM grows to ~1100Mb - R (redisplay page): RAM grows to ~1752Mb - R (redisplay page): RAM grows to ~2222Mb - rinse and repeat: RAM never goes down - (image-cache-size) reports a modest 82Mb - Kill buffer: high RAM consumption is still at its maximum, even after (image-cache-size) goes to 0 My impression is that this bad behaviour is not limited to animated gifts, although for regular images i don't have a solid recipe: what i observe is that running long sessions in term mode for days of continous use in an xterm, RAM tops at about 0.5Mb, while running similar sessions under X (using the same packages and doing the same kind of things inside of emacs), RAM will steadily increase. The only difference between the two scenarios i can think of is that in X i sometimes display images, mainly in eww and, sometimes, inside HTML email messages rendered via shr. I also observe that while it's pretty common for emacs in an x term (either run directly or connected to a demon) to release memory (i.e., to have its RSS decrease), that almost never happens when running under X: there RAM almost never goes down, no matter what. In GNU Emacs 29.0.50 (build 16, x86_64-pc-linux-gnu, cairo version 1.16.0) of 2022-07-14 built on rivendell Repository revision: 9a888323c60c60fb37f471ef03f0bcdff91cb850 Repository branch: master System Description: Debian GNU/Linux bookworm/sid Configured using: 'configure --prefix=/usr/local/stow/emacs --with-x-toolkit=no --with-imagemagick' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ IMAGEMAGICK JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY OLDXMENU PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF WEBP X11 XDBE XIM XINPUT2 XPM ZLIB Important settings: value of $LANG: en_GB.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: telega-root-auto-fill-mode: t telega-active-locations-mode: t telega-patrons-mode: t telega-mode-line-mode: t diff-hl-margin-mode: t global-diff-hl-mode: t eshell-vterm-mode: t eshell-syntax-highlighting-global-mode: t pdf-occur-global-minor-mode: t winner-mode: t global-git-commit-mode: t magit-auto-revert-mode: t global-auto-revert-mode: t shell-dirtrack-mode: t vertico-mode: t global-company-mode: t company-mode: t marginalia-mode: t persistent-scratch-autosave-mode: t global-so-long-mode: t pulsar-global-mode: t pulsar-mode: t display-battery-mode: t jao-minibuffer-mode: t minibuffer-electric-default-mode: t minibuffer-depth-indicate-mode: t xclip-mode: t repeat-mode: t savehist-mode: t recentf-mode: t save-place-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 file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t column-number-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: /home/jao/lib/elisp/org-static-blog/org-static-blog hides /home/jao/.emacs.d/elpa.29/org-static-blog-20220508.1410/org-static-blog /home/jao/etc/emacs/site/custom hides /usr/local/stow/emacs/share/emacs/29.0.50/lisp/custom /home/jao/.emacs.d/elpa.29/transient-20220527.2213/transient hides /usr/local/stow/emacs/share/emacs/29.0.50/lisp/transient Features: (shadow mailalias bbdb-message vertico-directory tramp-cmds sort gnus-cite mm-archive mail-extr textsec uni-scripts idna-mapping ucs-normalize uni-confusable textsec-check gnus-async gnus-bcklg gnus-dup qp gnus-ml gnus-topic nnml bbdb-gnus network-stream bbdb-mua gnus-icalendar icalendar ol-gnus nnselect org-capture gnus-delay gnus-draft gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-cache gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum nndraft nnmh gnus-demon nntp gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range gnus-win org-duration org-appear org-agenda org-refile cal-iso mule-util cal-move bigml bml-logs bml bml-misc bml-whizzml bml-clojure bml-clj-tests bml-python bml-skels bml-utils multisession sqlite whizzml-skeletons whizzml-mode lice sieve sieve-mode sieve-manage sasl sasl-anonymous sasl-login sasl-plain jao-mpc jao-random-album jao-lyrics jao-mpris telega-obsolete telega telega-tdlib-events telega-webpage visual-fill-column telega-match telega-root telega-info telega-chat telega-modes telega-company telega-user telega-notifications telega-voip telega-msg telega-tme telega-sticker telega-i18n telega-vvnote bindat telega-ffplay telega-sort telega-filter telega-ins telega-folders telega-inline telega-util telega-media telega-tdlib rainbow-identifiers dired-aux telega-server telega-core cursor-sensor telega-customize emacsbug jao-mullvad bluetooth enwc enwc-backend json-mode json-snatcher js cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs yaml-mode virtualenvwrapper gud ediprolog pie haskell-doc inf-haskell haskell-decl-scan haskell haskell-completions haskell-load haskell-commands highlight-uses-mode haskell-modules haskell-sandbox haskell-navigate-imports haskell-repl haskell-svg haskell-collapse hideshow haskell-debug haskell-interactive-mode haskell-presentation-mode haskell-compile haskell-hoogle haskell-process haskell-session haskell-mode haskell-cabal haskell-utils haskell-font-lock haskell-indentation haskell-string haskell-sort-imports haskell-lexeme haskell-align-imports haskell-complete-module haskell-ghc-support flymake-proc flymake warnings dabbrev haskell-customize geiser-guile info-look geiser-repl geiser-compile geiser-debug geiser-image geiser-capf geiser-doc geiser-menu geiser-edit etags fileloop xref project geiser-completion geiser-autodoc geiser-eval geiser-connection geiser-syntax scheme geiser-impl help-fns radix-tree geiser-log geiser-popup view geiser-custom geiser-base geiser idris-mode idris-commands idris-hole-list idris-ipkg-mode idris-tree-info idris-warnings-tree idris-info idris-repl idris-highlight-input idris-prover inferior-idris idris-warnings idris-log idris-events idris-simple-indent idris-syntax idris-common-utils idris-settings idris-keys idris-core idris-compat prop-menu package-lint finder lisp-mnt edit-list outline-minor-faces git-modes gitignore-mode gitconfig-mode conf-mode gitattributes-mode git-link git-timemachine diff-hl-margin diff-hl-dired diff-hl log-view vc-dir ewoc vc jao-eshell-here eshell-autojump em-dirs esh-var eshell-up git-ps1-mode eshell-vterm em-term eshell-syntax-highlighting em-alias vterm tramp tramp-loaddefs trampver tramp-integration files-x tramp-compat ls-lisp face-remap term ehelp vterm-module term/xterm xterm jao-custom-email bbdb-anniv bbdb-com bbdb bbdb-site timezone randomsig nov esxml-query saveplace-pdf-view pdf-occur ibuf-ext ibuffer ibuffer-loaddefs tablist tablist-filter semantic/wisent/comp semantic/wisent semantic/wisent/wisent semantic/util-modes semantic/util semantic semantic/tag semantic/lex semantic/fw mode-local cedet pdf-isearch pdf-misc socks elpher jao-custom-eww ol-eww jao-eww-session eww xdg url-queue mm-url gnus nnheader range markdown-toc jao-custom-blog htmlize jao-custom-org jao-org-links jao-doc-view doc-view pdf-tools pdf-view pdf-cache pdf-info tq pdf-util pdf-macs image-mode exif ol-info ol-eshell esh-mode eshell esh-cmd esh-ext esh-opt esh-proc esh-io esh-arg esh-module esh-groups esh-util jao-org-notes ob-shell ob-scheme ob-python python ob-org ob-ocaml ob-makefile ob-haskell ob-gnuplot ob-clojure ob-calc calc-store calc-trail ob-prolog prolog smie align org-tempo tempo ox-texinfo ox-latex ox-html table ox-ascii ox-publish ox org-fragtog org-element avl-tree generator jao-afio winner consult-recoll embark-consult consult-vertico consult compat-28 magit-bookmark bookmark jao-recoll org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-footnote org-src ob-comint org-pcomplete org-list org-faces org-entities org-version ob-emacs-lisp ob-core ob-eval org-table oc-basic bibtex ol org-keys oc org-compat org-macs org-loaddefs find-func jao-custom-completion embark-vc s code-review code-review-actions code-review-comment code-review-section code-review-bitbucket code-review-faces shr pixel-fill kinsoku url-file url-dired svg dom emojify apropos tar-mode arc-mode archive-mode ht code-review-gitlab code-review-utils code-review-parse-hunk code-review-github code-review-db uuidgen calc-misc calc-ext calc calc-loaddefs rect calc-macs a code-review-interfaces deferred forge-list forge-commands forge-semi forge-bitbucket buck forge-gogs gogs forge-gitea gtea forge-gitlab glab forge-github ghub-graphql treepy gsexp ghub let-alist gnutls forge-notify forge-revnote forge-pullreq forge-issue forge-topic yaml parse-time iso8601 bug-reference forge-post markdown-mode edit-indirect noutline outline forge-repo forge forge-core forge-db closql emacsql-sqlite advice emacsql emacsql-compiler url-http url-auth url-gw nsm magit-submodule magit-obsolete 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 message sendmail yank-media puny rfc822 mml mml-sec gnus-util time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader pcvs-util add-log magit-core magit-autorevert autorevert filenotify magit-margin magit-transient magit-process with-editor shell pcomplete magit-mode magit-git magit-base magit-section crm dash compat-27 compat-26 embark ffap thingatpt vertico company-keywords company-dabbrev company-files company-capf company pcase marginalia orderless imenu jao-skel-latex jao-skel-haskell jao-compilation jao-skel-lisp jao-skel-geiser jao-skel skeleton autoinsert wgrep grep compile text-property-search comint ring jka-compr dired-x dired dired-loaddefs persistent-scratch so-long cal-china lunar solar cal-dst cal-bahai cal-islam cal-hebrew holidays holiday-loaddefs vc-git diff-mode vc-dispatcher appt diary-lib diary-loaddefs cal-menu calendar cal-loaddefs pulsar pulse color tmr jao-tracking tracking shorten jao-notify alert log4e notifications gntp battery jao-mode-line jao-minibuffer minibuf-eldef mb-depth xclip diminish jao-light-term-theme jao-themes ansi-color disp-table server pinentry epa-file epa derived epg rfc6068 epg-config transient format-spec compat cus-edit pp cus-load repeat edmacro kmacro jao-shell jao-sleep dbus xml savehist recentf tree-widget wid-edit saveplace jao-gnus-private gnu-elpa-keyring-update cl-extra help-mode use-package use-package-ensure use-package-delight use-package-diminish use-package-bind-key bind-key easy-mmode use-package-core finder-inf tex-site bbdb-autoloads cider-autoloads clojure-mode-autoloads company-autoloads diff-hl-autoloads edit-indirect-autoloads elpher-autoloads embark-consult-autoloads consult-autoloads embark-vc-autoloads embark-autoloads code-review-autoloads forge-autoloads ghub-autoloads git-link-autoloads idris-mode-autoloads json-mode-autoloads rx link-hint-autoloads magit-autoloads git-commit-autoloads magit-section-autoloads marginalia-autoloads markdown-mode-autoloads org-appear-autoloads org-fragtog-autoloads outline-minor-faces-autoloads paredit-autoloads pdf-tools-autoloads persistent-scratch-autoloads pulsar-autoloads racket-mode-autoloads request-autoloads switch-window-autoloads telega-autoloads tmr-autoloads vertico-autoloads dash-autoloads vterm-autoloads with-editor-autoloads info compat-autoloads xclip-autoloads yaml-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 password-cache json subr-x map byte-opt gv bytecomp byte-compile cconv url-vars cl-loaddefs cl-lib rmc iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd 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 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 dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting cairo xinput2 x multi-tty make-network-process emacs) Memory information: ((conses 16 1050346 86454) (symbols 48 89440 112) (strings 32 323218 19301) (string-bytes 1 9679236) (vectors 16 148160) (vector-slots 8 2070697 64427) (floats 8 1357 901) (intervals 56 4457 7319) (buffers 992 29)) -- The greatest of faults, I should say, is to be conscious of none. -Thomas Carlyle, writer (1795-1881) From unknown Thu Aug 14 22:14:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#56546: 29.0.50; unbounded RAM comsumption when displaying images Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Jul 2022 05:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56546 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Jose A. Ortega Ruiz" Cc: 56546@debbugs.gnu.org Received: via spool by 56546-submit@debbugs.gnu.org id=B56546.165777753918161 (code B ref 56546); Thu, 14 Jul 2022 05:46:01 +0000 Received: (at 56546) by debbugs.gnu.org; 14 Jul 2022 05:45:39 +0000 Received: from localhost ([127.0.0.1]:48419 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oBrfP-0004ir-Fd for submit@debbugs.gnu.org; Thu, 14 Jul 2022 01:45:39 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34082) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oBrfM-0004id-EA for 56546@debbugs.gnu.org; Thu, 14 Jul 2022 01:45:38 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37932) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBrfG-00062o-VL; Thu, 14 Jul 2022 01:45:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=vuwnGn4C1O1jstjE23UZ58ZcUPDOkqRoCxtAG8W3sdQ=; b=r5XAkiwK9WJr IRmJTkTTqA4IVRZ1/KMpmhCWD+JltM+jZ3fVs0pM2j0mUvp4DN6WAfhPTponB35pMwLpReAw/zR+p YOAJgszyINcP1us/cdrROoBvL0GzaECXNGQ475EuzAAQUX8PWoDGsQYAgaklnXDxMlOgLTP44ncC8 zTReJEbYyyyyT9AkgpoPx3/rChx2KOtz5JtbaTUhrd0/5JrHeBoTUlO5T4GzLYKdNOCaQgR/akvbY 9KgVLCR4S6NT6/UuxNnzJOUtaHUqWjjovWFUGbNRqsYvNxRFdUIbisMWIEi2xysoPuIKt0ySWTeD6 zmUHd4HTIJXT5hZ06PewJQ==; Received: from [87.69.77.57] (port=4472 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBrfG-0006uN-0u; Thu, 14 Jul 2022 01:45:30 -0400 Date: Thu, 14 Jul 2022 08:45:24 +0300 Message-Id: <8335f4uu17.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87cze84gst.fsf@mail.jao.io> References: <87cze84gst.fsf@mail.jao.io> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: "Jose A. Ortega Ruiz" > Date: Thu, 14 Jul 2022 02:35:46 +0100 > > > It seems to be easy to make emacs (under X) to consume more and more > RAM, which is never released, by making it display images. A extreme > (in my experience) case is animated GIFs, try: > > - emacs -Q > - M-x eww RET https://xenodium.com/emacs-zones-to-lift-you-up/ > - RAM consumption grows to ~600Mb > - R (redisplay page): RAM grows to ~1100Mb > - R (redisplay page): RAM grows to ~1752Mb > - R (redisplay page): RAM grows to ~2222Mb > - rinse and repeat: RAM never goes down > - (image-cache-size) reports a modest 82Mb > - Kill buffer: high RAM consumption is still at its maximum, even > after (image-cache-size) goes to 0 Run some utility that displays the memory-map of an application, and you will see that most of that memory is free for use. Emacs just didn't release it to the OS, but kept it in the memory pages allocated to the process, for future allocations. The strategy for releasing memory to the OS is in glibc, not under our control. Last time we talked with glibc developers, they maintained that this is the expected and correct behavior. From unknown Thu Aug 14 22:14:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#56546: 29.0.50; unbounded RAM comsumption when displaying images Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Jul 2022 06:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56546 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: mail@jao.io Cc: 56546@debbugs.gnu.org Received: via spool by 56546-submit@debbugs.gnu.org id=B56546.165777870820159 (code B ref 56546); Thu, 14 Jul 2022 06:06:02 +0000 Received: (at 56546) by debbugs.gnu.org; 14 Jul 2022 06:05:08 +0000 Received: from localhost ([127.0.0.1]:48429 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oBryF-0005F5-Vt for submit@debbugs.gnu.org; Thu, 14 Jul 2022 02:05:08 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37770) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oBryD-0005EV-Eo for 56546@debbugs.gnu.org; Thu, 14 Jul 2022 02:05:06 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38162) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBry8-0001ZE-0j; Thu, 14 Jul 2022 02:05:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=m/D1DuDlecg4w/nxgQ+S8K/hcjCURKT6oLe4aX/ah7A=; b=pbJJmIPMySYC 0Y/Bpx8QAeW25OnWPi6TiKgnCmP2AGAF1eQt23zU5wGRmzg6ao0T54zVCrivL4WjpTzm339HIIItn 83fWKItTWqUaozfy8eG08Nescnl7nnJkd1BzCxkcdqc14YguLhbSjNkRGNhfNSsyPmYQFtbUbwZi6 Pmb2QwOPXV2q6KN3Ic/PwO6XmZlciTHJ0xJFiONm7f15WN7/o0mLI9FtIJ64wima916MavqbwQN5M uAGv8vZRsGfBo76MJKTY1g2di2L+jXfMBrn4CRbdIWZJRV+3nFzXiPDdOqH2gHK9ieSFfLA7JTwU5 b9DuS/vwzHMVecOttltdRg==; Received: from [87.69.77.57] (port=1740 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBry6-0007gL-Vi; Thu, 14 Jul 2022 02:04:59 -0400 Date: Thu, 14 Jul 2022 09:04:51 +0300 Message-Id: <83zghctekc.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <8335f4uu17.fsf@gnu.org> (message from Eli Zaretskii on Thu, 14 Jul 2022 08:45:24 +0300) References: <87cze84gst.fsf@mail.jao.io> <8335f4uu17.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 56546@debbugs.gnu.org > Date: Thu, 14 Jul 2022 08:45:24 +0300 > From: Eli Zaretskii > > > From: "Jose A. Ortega Ruiz" > > Date: Thu, 14 Jul 2022 02:35:46 +0100 > > > > > > It seems to be easy to make emacs (under X) to consume more and more > > RAM, which is never released, by making it display images. A extreme > > (in my experience) case is animated GIFs, try: > > > > - emacs -Q > > - M-x eww RET https://xenodium.com/emacs-zones-to-lift-you-up/ > > - RAM consumption grows to ~600Mb > > - R (redisplay page): RAM grows to ~1100Mb > > - R (redisplay page): RAM grows to ~1752Mb > > - R (redisplay page): RAM grows to ~2222Mb > > - rinse and repeat: RAM never goes down > > - (image-cache-size) reports a modest 82Mb > > - Kill buffer: high RAM consumption is still at its maximum, even > > after (image-cache-size) goes to 0 > > Run some utility that displays the memory-map of an application, and > you will see that most of that memory is free for use. Emacs just > didn't release it to the OS, but kept it in the memory pages allocated > to the process, for future allocations. > > The strategy for releasing memory to the OS is in glibc, not under our > control. Last time we talked with glibc developers, they maintained > that this is the expected and correct behavior. Btw, did you try M-: (clear-image-cache) RET followed by "M-x garbage-collect RET"? From unknown Thu Aug 14 22:14:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#56546: 29.0.50; unbounded RAM comsumption when displaying images Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Jul 2022 08:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56546 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: mail@jao.io, 56546@debbugs.gnu.org Received: via spool by 56546-submit@debbugs.gnu.org id=B56546.16577888104709 (code B ref 56546); Thu, 14 Jul 2022 08:54:02 +0000 Received: (at 56546) by debbugs.gnu.org; 14 Jul 2022 08:53:30 +0000 Received: from localhost ([127.0.0.1]:48724 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oBubC-0001Dt-3T for submit@debbugs.gnu.org; Thu, 14 Jul 2022 04:53:30 -0400 Received: from quimby.gnus.org ([95.216.78.240]:60938) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oBub7-0001DX-7w for 56546@debbugs.gnu.org; Thu, 14 Jul 2022 04:53:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=2mWIMuTrlZYSJepC6FYwKeY88gHk/N5KCLNnicFwkwU=; b=ROtNDaa6y+CqVZz7KJbEZ0deUw c1l7JU6OVLVihz8DVYe1b8B9Oif+Zx/OLVvNH5cceeeyN75TXw6nqj6nqfaWaHBbEzwAN6idZrtSI gCWWnTbaL0dEnbznkkqrrxpKR87VtMOf4OzUoKCCz3BFyKmopq9VZQcfui4ex669t06M=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oBuaw-0000E4-BA; Thu, 14 Jul 2022 10:53:17 +0200 From: Lars Ingebrigtsen In-Reply-To: <83zghctekc.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 14 Jul 2022 09:04:51 +0300") References: <87cze84gst.fsf@mail.jao.io> <8335f4uu17.fsf@gnu.org> <83zghctekc.fsf@gnu.org> X-Now-Playing: The Ascension Plan's _All Ways EP_: "Old Wings" Date: Thu, 14 Jul 2022 10:53:12 +0200 Message-ID: <87r12onkhz.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > Btw, did you try > > M-: (clear-image-cache) RET The problem is the animation cache, not the image cache, I think. And I see that I forgot to make clear-image-cache clear the animation cache, which it should. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > Btw, did you try > > M-: (clear-image-cache) RET The problem is the animation cache, not the image cache, I think. And I see that I forgot to make clear-image-cache clear the animation cache, which it should. And also -- the animation cache should be pruned regularly, but it's not only pruned when doing animated images. I think it should also be pruned from... gc? Or is there a different place it'd make sense to prune that cache from? Finally, image-cache-size should also report the animation cache size, I think. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Thu Aug 14 22:14:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#56546: 29.0.50; unbounded RAM comsumption when displaying images Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Jul 2022 09:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56546 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: mail@jao.io, 56546@debbugs.gnu.org Received: via spool by 56546-submit@debbugs.gnu.org id=B56546.16577901757035 (code B ref 56546); Thu, 14 Jul 2022 09:17:02 +0000 Received: (at 56546) by debbugs.gnu.org; 14 Jul 2022 09:16:15 +0000 Received: from localhost ([127.0.0.1]:48750 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oBuxD-0001pO-H5 for submit@debbugs.gnu.org; Thu, 14 Jul 2022 05:16:15 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58730) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oBux9-0001p8-EE for 56546@debbugs.gnu.org; Thu, 14 Jul 2022 05:16:14 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40308) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBux3-00085j-N4; Thu, 14 Jul 2022 05:16:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ExP9U4j+rQMVEwgj1Qq2O5XVpiCtxtuJxtKPgIvnVv4=; b=LRkrnL46zCVo lXx7Uc3tI2Ch3mcDWUHHB+E8sFccMg1TwpvLqs6154Ibxbp65VXqMVC94o2T+wlRcqh6IpS6tEqOA ikWAEtJs34DpwxH9SKfHhev3oOg6pEGXU5UV24AQuWORkK/kJeg5FvATJt68faTyn+8dDQKrJYdKh eN04HhIc1qk6qPFC7DDrQER8B7OHJiFyKXoy2s4A8ypiF0E8lgKgCn1xkB6PgS11VjlHKNaajE/c/ DPjLVDEGsAmYze0NMH+s5DdU9MH6g2u8YrgVS0P26SUOC9C1UINgkZIzbBAkakMyVUjfTpRFNdCJD PTr/zxhQSj+aLFgAyR3Vxg==; Received: from [87.69.77.57] (port=2057 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBuwu-0005Rw-Lg; Thu, 14 Jul 2022 05:16:03 -0400 Date: Thu, 14 Jul 2022 12:15:50 +0300 Message-Id: <83leswt5q1.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87r12onkhz.fsf@gnus.org> (message from Lars Ingebrigtsen on Thu, 14 Jul 2022 10:53:12 +0200) References: <87cze84gst.fsf@mail.jao.io> <8335f4uu17.fsf@gnu.org> <83zghctekc.fsf@gnu.org> <87r12onkhz.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: mail@jao.io, 56546@debbugs.gnu.org > Date: Thu, 14 Jul 2022 10:53:12 +0200 > > Eli Zaretskii writes: > > > Btw, did you try > > > > M-: (clear-image-cache) RET > > The problem is the animation cache, not the image cache, I think. And I > see that I forgot to make clear-image-cache clear the animation cache, > which it should. When we remove an image from the cache, its animations should also be removed, I agree. > And also -- the animation cache should be pruned regularly, but it's not > only pruned when doing animated images. I think it should also be > pruned from... gc? Or is there a different place it'd make sense to > prune that cache from? GC could be problematic. Imagine someone who has a frame displayed at all times animating something -- you don't want to clear those caches, right? I think we should perhaps track which images are actually displayed, and when was the last time they were displayed, and evict them from the cache after enough time has passed since the image was last displayed. > Finally, image-cache-size should also report the animation cache size, I > think. That'd help, yes. From unknown Thu Aug 14 22:14:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#56546: 29.0.50; unbounded RAM comsumption when displaying images Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Jul 2022 09:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56546 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: mail@jao.io, 56546@debbugs.gnu.org Received: via spool by 56546-submit@debbugs.gnu.org id=B56546.16577904747563 (code B ref 56546); Thu, 14 Jul 2022 09:22:02 +0000 Received: (at 56546) by debbugs.gnu.org; 14 Jul 2022 09:21:14 +0000 Received: from localhost ([127.0.0.1]:48759 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oBv21-0001xu-CV for submit@debbugs.gnu.org; Thu, 14 Jul 2022 05:21:13 -0400 Received: from quimby.gnus.org ([95.216.78.240]:32906) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oBv1t-0001x0-Ik for 56546@debbugs.gnu.org; Thu, 14 Jul 2022 05:21:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=nOo42JdF5gPTkl5LLuIk5+dMbzyphfpBLArBIu+kcSs=; b=Qw0hu3UttbZ0OqstDoFetm8wV0 gr1MtCHeXl2yD7e+DN0WYCwK3Fd3qdHey4GVv0Q+mgFVRkGrhnkUUSgMY23RcfruRgyhjcKeDwBFb uGd0MemNlECdrl9R2F3nWhiA/RGh5PAIdP36Gt0M5ZBSgS/3eZpQ4wxPclAcU/zLZaCs=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oBv1j-0000QR-Jv; Thu, 14 Jul 2022 11:20:58 +0200 From: Lars Ingebrigtsen In-Reply-To: <83leswt5q1.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 14 Jul 2022 12:15:50 +0300") References: <87cze84gst.fsf@mail.jao.io> <8335f4uu17.fsf@gnu.org> <83zghctekc.fsf@gnu.org> <87r12onkhz.fsf@gnus.org> <83leswt5q1.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAGFBMVEUjKmgXFhYoNYhW OzelbVLozLE2UKr///+StNrBAAAAAWJLR0QHFmGI6wAAAAd0SU1FB+YHDgkQODMnaFwAAAFySURB VDjLddPNcoMgEABgAmnPopmeGRI9y6wPUEd8gUbunXTq+z9CWf4EtXswM3wsu7iRkCw4RkWplFKQ E5A7oEw5iRCNCoBhiiAJkWFdCpiXHITw+6W4GQdVzLAPgU8LJgeKQD0sQ5nhEqS86hGwrQ1CPPS4 ywjRmvFmr1IfM4xq/oERARvpCpC+2259ye6VQffSCO+riwzWdTgC/qwrQ6gzEKDw6PXb3a/bAMDv /HHzqBPcIexkDnwVBObh4+4n6MVnuJUGeIw6Zii+i6pDaPXID4Hwa/Q5XJdJnUI7aigWVTxKzUWR JgN1Cu2iz+Ex6WIxQbdMqTjetYld2ZGmo3BHBrBlNGq7hy3/nEIJBJXBkoAXGW/meQT7xVxmo9NM NiAEjNH6ErpKYD+92VjxE2y2tyt6gjCpipWv3cPCeb8HLGG7avp4twCkZxZAVfyyAzLYBFbtR0vv YOET0mtNwBgxpnenVCo/yor5Yiz9C0L8AfpLhpuKBe+qAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIy LTA3LTE0VDA5OjE2OjU2KzAwOjAwW1A9zAAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMi0wNy0xNFQw OToxNjo1NiswMDowMCoNhXAAAAAASUVORK5CYII= X-Now-Playing: Richard and Linda Thompson's _Hard Luck Stories (6): First Light_: "Restless Highways" Date: Thu, 14 Jul 2022 11:20:53 +0200 Message-ID: <87mtdcnj7u.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > When we remove an image from the cache, its animations should also be > removed, I agree. The image cache is for displayed images, so an animated image will usually have dozens of image cache entries, so it doesn't work that way. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > When we remove an image from the cache, its animations should also be > removed, I agree. The image cache is for displayed images, so an animated image will usually have dozens of image cache entries, so it doesn't work that way. > GC could be problematic. Imagine someone who has a frame displayed at > all times animating something -- you don't want to clear those caches, > right? No, but the cache should be pruned of old entries. (Which is what the pruning function does.) >> Finally, image-cache-size should also report the animation cache size, I >> think. > > That'd help, yes. Looking at that now, that's easier said than done, because the animation caches are opaque -- we call out to support libraries, and it doesn't look like all of them have a way to say how much memory they use. (I'm looking at the webp functions right now...) But we can at least include the size of the main data blob (e.g., the .webp data itself); we know the size of that for all the anim caches. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Thu Aug 14 22:14:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#56546: 29.0.50; unbounded RAM comsumption when displaying images Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Jul 2022 10:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56546 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: mail@jao.io, 56546@debbugs.gnu.org Received: via spool by 56546-submit@debbugs.gnu.org id=B56546.165779289111998 (code B ref 56546); Thu, 14 Jul 2022 10:02:02 +0000 Received: (at 56546) by debbugs.gnu.org; 14 Jul 2022 10:01:31 +0000 Received: from localhost ([127.0.0.1]:48896 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oBvf0-00037R-KZ for submit@debbugs.gnu.org; Thu, 14 Jul 2022 06:01:30 -0400 Received: from quimby.gnus.org ([95.216.78.240]:33192) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oBvey-00037B-0j for 56546@debbugs.gnu.org; Thu, 14 Jul 2022 06:01:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=tqcL/FtJLALPgbcbXoh6b/0YG7G0DbZhLkQSr8EdM50=; b=Qh0MtEOWaugxDy6+gngFVdlQwJ nU8gCKoH9fQqvrn82OgrlcCR6uqyBaXc2R2pqXqkoiODBhBxQR3CnuKfEVPa6V7FkPYmr+zgrvyxk ZEZdijEzTK//WRqSZ8HqP7sBQJoLHUAO5IQf6Zcf1ZEtHCoS/XlopKsshJnUnMgLm/48=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oBven-0000fx-Qu; Thu, 14 Jul 2022 12:01:20 +0200 From: Lars Ingebrigtsen In-Reply-To: <87mtdcnj7u.fsf@gnus.org> (Lars Ingebrigtsen's message of "Thu, 14 Jul 2022 11:20:53 +0200") References: <87cze84gst.fsf@mail.jao.io> <8335f4uu17.fsf@gnu.org> <83zghctekc.fsf@gnu.org> <87r12onkhz.fsf@gnus.org> <83leswt5q1.fsf@gnu.org> <87mtdcnj7u.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAGFBMVEUjKmgXFhYoNYhW OzelbVLozLE2UKr///+StNrBAAAAAWJLR0QHFmGI6wAAAAd0SU1FB+YHDgkyBLv6UvsAAAFySURB VDjLddPNcoMgEABgAmnPopmeGRI9y6wPUEd8gUbunXTq+z9CWf4EtXswM3wsu7iRkCw4RkWplFKQ E5A7oEw5iRCNCoBhiiAJkWFdCpiXHITw+6W4GQdVzLAPgU8LJgeKQD0sQ5nhEqS86hGwrQ1CPPS4 ywjRmvFmr1IfM4xq/oERARvpCpC+2259ye6VQffSCO+riwzWdTgC/qwrQ6gzEKDw6PXb3a/bAMDv /HHzqBPcIexkDnwVBObh4+4n6MVnuJUGeIw6Zii+i6pDaPXID4Hwa/Q5XJdJnUI7aigWVTxKzUWR JgN1Cu2iz+Ex6WIxQbdMqTjetYld2ZGmo3BHBrBlNGq7hy3/nEIJBJXBkoAXGW/meQT7xVxmo9NM NiAEjNH6ErpKYD+92VjxE2y2tyt6gjCpipWv3cPCeb8HLGG7avp4twCkZxZAVfyyAzLYBFbtR0vv YOET0mtNwBgxpnenVCo/yor5Yiz9C0L8AfpLhpuKBe+qAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIy LTA3LTE0VDA5OjUwOjA0KzAwOjAwOeghRAAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMi0wNy0xNFQw OTo1MDowNCswMDowMEi1mfgAAAAASUVORK5CYII= X-Now-Playing: Richard and Linda Thompson's _Hard Luck Stories (6): First Light_: "Pavanne" Date: Thu, 14 Jul 2022 12:01:16 +0200 Message-ID: <87h73kau8j.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Lars Ingebrigtsen writes: > But we can at least include the size of the main data blob (e.g., the > .webp data itself); we know the size of that for all the anim caches. No, not even that -- the cache is pretty opaque in general. Hm... Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Lars Ingebrigtsen writes: > But we can at least include the size of the main data blob (e.g., the > .webp data itself); we know the size of that for all the anim caches. No, not even that -- the cache is pretty opaque in general. Hm... -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Thu Aug 14 22:14:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#56546: 29.0.50; unbounded RAM comsumption when displaying images Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Jul 2022 10:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56546 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: mail@jao.io, 56546@debbugs.gnu.org Received: via spool by 56546-submit@debbugs.gnu.org id=B56546.165779342212883 (code B ref 56546); Thu, 14 Jul 2022 10:11:02 +0000 Received: (at 56546) by debbugs.gnu.org; 14 Jul 2022 10:10:22 +0000 Received: from localhost ([127.0.0.1]:48914 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oBvna-0003Lj-HZ for submit@debbugs.gnu.org; Thu, 14 Jul 2022 06:10:22 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46384) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oBvnW-0003LV-NT for 56546@debbugs.gnu.org; Thu, 14 Jul 2022 06:10:21 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40772) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBvnQ-0004er-TA; Thu, 14 Jul 2022 06:10:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=etkWNagSnNVDJOkU9jhEavHa7sxXTRof84NkREYsHWo=; b=SabgHTBNB/vH Y41vTEgNYogA2f9rUXlvWo4g88iqrgyhziCzRn38uzsIFcm7wG1H66wX9ZVc1I1gJHlKdOxm/QwuG nuvVHpG7pmA3UzwJHM1RXB1v0zl2qetnnYT4/+p+oQol5PutAqH4utAKOFSjosmzuGA0MdLkqku54 2OQMQMDhDq5UWy6RG91TYTiLTxtfYUUR4Wd8csjg2cOY9N84hKvnXXGfzZy5qS3jLhux9qaD6yude FuvCtxeHeMa1BKRaEoYknhppZvFco2kyU7Q3vIVbSpNJD9Uh8oa/mpAC928nrC3AuZYZhUcEvOD7d PiSLH4awpd/EudRLHzAHKw==; Received: from [87.69.77.57] (port=1431 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBvnO-00026h-O9; Thu, 14 Jul 2022 06:10:12 -0400 Date: Thu, 14 Jul 2022 13:10:04 +0300 Message-Id: <83k08gt37n.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87h73kau8j.fsf@gnus.org> (message from Lars Ingebrigtsen on Thu, 14 Jul 2022 12:01:16 +0200) References: <87cze84gst.fsf@mail.jao.io> <8335f4uu17.fsf@gnu.org> <83zghctekc.fsf@gnu.org> <87r12onkhz.fsf@gnus.org> <83leswt5q1.fsf@gnu.org> <87mtdcnj7u.fsf@gnus.org> <87h73kau8j.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: mail@jao.io, 56546@debbugs.gnu.org > Date: Thu, 14 Jul 2022 12:01:16 +0200 > > Lars Ingebrigtsen writes: > > > But we can at least include the size of the main data blob (e.g., the > > .webp data itself); we know the size of that for all the anim caches. > > No, not even that -- the cache is pretty opaque in general. Hm... Don't we allocate memory for the cached stuff? If so, we could count the bytes there, and record them in the cache itself. From unknown Thu Aug 14 22:14:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#56546: 29.0.50; unbounded RAM comsumption when displaying images Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Jul 2022 10:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56546 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: mail@jao.io, 56546@debbugs.gnu.org Received: via spool by 56546-submit@debbugs.gnu.org id=B56546.165779371513509 (code B ref 56546); Thu, 14 Jul 2022 10:16:01 +0000 Received: (at 56546) by debbugs.gnu.org; 14 Jul 2022 10:15:15 +0000 Received: from localhost ([127.0.0.1]:48940 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oBvsJ-0003Vl-9B for submit@debbugs.gnu.org; Thu, 14 Jul 2022 06:15:15 -0400 Received: from quimby.gnus.org ([95.216.78.240]:33382) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oBvsH-0003VQ-Pt for 56546@debbugs.gnu.org; Thu, 14 Jul 2022 06:15:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=GQ4SgYzKaHep0TV2nyybfHeQSklzyjCMRN2HKHfdAlA=; b=Oqy3flKlZpfBEYi2qVv8f7y/WY HXF5V0HmSwpy+w1yVi4aaiDMdPVLpiNVgwL9fUazUpFoGbgphWrvE/qHki/b3q7tWahZmQgW3g0jm /UiC/cQUwDZ02tc7LFg8wRkfnAkX82IquAyCT+sWp1pG9koCou7QmX9vE+tXLrP/+6ko=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oBvs8-0000q0-EW; Thu, 14 Jul 2022 12:15:06 +0200 From: Lars Ingebrigtsen In-Reply-To: <83k08gt37n.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 14 Jul 2022 13:10:04 +0300") References: <87cze84gst.fsf@mail.jao.io> <8335f4uu17.fsf@gnu.org> <83zghctekc.fsf@gnu.org> <87r12onkhz.fsf@gnus.org> <83leswt5q1.fsf@gnu.org> <87mtdcnj7u.fsf@gnus.org> <87h73kau8j.fsf@gnus.org> <83k08gt37n.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEVsdXsdFBTh08v/ //8dPTZQAAAAAWJLR0QDEQxM8gAAAAlwSFlzAAALEgAACxIB0t1+/AAAAAd0SU1FB+YHDgoCB//z i+sAAAFbSURBVCjPTdG9bsIwEAfwAxUJeaJRIiGmlgn5KRIEQzOFyNehT1DxFFEm5KkdWJiCpUru /yl751BElA//ch92HJoxE02YuSEifZQKN8LRI3IF39Kenh+Q0lT3GuaS0qsRTQJXcu0P7g5X0i3S yIl4g2Nugd0jtMZxkxA1cqiWcm9Cl2rKldy36NKklRkKPl7mE8H+bRsLrrOoKGg6zHibDVrjqL9O uPZgrdn0seIaUeDyjYl7wa+CjJcGH1ONcGlxKjRtJtglNJkdtIHBlXkBRF3VGq/sOttDGjjyPy7v jIemtb54zwfrQ9oqe26ziIum8WHN7SoGk9KqwMZgOCbwoqgt4meC+26WMosF7Znzr7wXACS/se2p g4dA9rwOp5cxEhtZsF8DQYB5UQMWehBwFuj7BJ0EYwNFxHiQFYRxHGjqC4vQjxiMfDaN7Ug+vJah 0fYELxH843RH+ANNCdcrFLJgDgAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMi0wNy0xNFQxMDowMjow NyswMDowMGc4rDgAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjItMDctMTRUMTA6MDI6MDcrMDA6MDAW ZRSEAAAAAElFTkSuQmCC X-Now-Playing: Mimi Goese and Ben Neill's _Life You Are_: "Ocean Rain" Date: Thu, 14 Jul 2022 12:15:03 +0200 Message-ID: <878rowatlk.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > Don't we allocate memory for the cached stuff? If so, we could count > the bytes there, and record them in the cache itself. No, we just call the gif/webp functions, and they allocate stuff on their own. For webp, we do know the size of the main data blob, but not for GIF -- we just call DGifOpenFileName+DGifSlurp, and look [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > Don't we allocate memory for the cached stuff? If so, we could count > the bytes there, and record them in the cache itself. No, we just call the gif/webp functions, and they allocate stuff on their own. For webp, we do know the size of the main data blob, but not for GIF -- we just call DGifOpenFileName+DGifSlurp, and looking over the documentation, there doesn't seem to be any way to get it to cough up how much data it allocated. In the non-file case, we know the size of the data blob, and I guess we could just see how big the GIF file is in the DGifOpenFileName case, and assume that it allocates memory for the entire file. (Which may or may not be true -- perhaps it uses mmap into the file instead, or whatever...) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Thu Aug 14 22:14:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#56546: 29.0.50; unbounded RAM comsumption when displaying images Resent-From: "Jose A. Ortega Ruiz" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Jul 2022 12:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56546 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 56546@debbugs.gnu.org Received: via spool by 56546-submit@debbugs.gnu.org id=B56546.165780139311158 (code B ref 56546); Thu, 14 Jul 2022 12:24:02 +0000 Received: (at 56546) by debbugs.gnu.org; 14 Jul 2022 12:23:13 +0000 Received: from localhost ([127.0.0.1]:49072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oBxs8-0002tu-L1 for submit@debbugs.gnu.org; Thu, 14 Jul 2022 08:23:12 -0400 Received: from relay1-d.mail.gandi.net ([217.70.183.193]:35673) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oBxs5-0002tZ-7h for 56546@debbugs.gnu.org; Thu, 14 Jul 2022 08:23:11 -0400 Received: (Authenticated sender: mail@jao.io) by mail.gandi.net (Postfix) with ESMTPSA id 8B2A624000C; Thu, 14 Jul 2022 12:23:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jao.io; s=gm1; t=1657801383; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=h/Sz+k6ah3na+X6aPc244ol36kCZ8MrH51iqs6LeDXY=; b=SFUN/qbyTI89lehpbJ9a45vBKOP8PmhpFRIYkepAB7Db6KhFmMVOUlbiP4mYN8TBzXUco1 yBvN8H94kZMjAJbu4XyhqwnWkD1VDS3W03gyugDZ+Rkv/NTLSimso6Gm9c2x6mHYomIBMU jFrMdQvNLsdpSreSISdy4OWrguHXR6CN4V+Opwp+yNO49V+GtZ053ylxLCYM8gNwseMsxY 1v/C50GFt34z034K8SqGjowuSvrechySU3KY53y8NT5kvZg9cBfsY8TWm79r3/criMrfKr YUEfhRx02jvh4hfCDbeYHtotVw6OU/FN4kHz+oBTtN5ZHA8wRbHKCIUe7jDgDg== Received: from localhost (rivendell.localdomain [local]) by rivendell.localdomain (OpenSMTPD) with ESMTPA id 90b99f9a; Thu, 14 Jul 2022 12:23:01 +0000 (UTC) From: "Jose A. Ortega Ruiz" In-Reply-To: <8335f4uu17.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 14 Jul 2022 08:45:24 +0300") References: <87cze84gst.fsf@mail.jao.io> <8335f4uu17.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) X-Attribution: jao X-Clacks-Overhead: GNU Terry Pratchett X-URL: Date: Thu, 14 Jul 2022 13:23:01 +0100 Message-ID: <87h73j3mu2.fsf@mail.jao.io> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On Thu, Jul 14 2022, Eli Zaretskii wrote: >> From: "Jose A. Ortega Ruiz" >> Date: Thu, 14 Jul 2022 02:35:46 +0100 >> >> >> It seems to be easy to make emacs (under X) to consume more and more >> RAM, which is never released, by making it display images. A extreme >> (in my experience) case is animated GIFs, try: >> >> - emacs -Q >> - M-x eww RET https://xenodium.com/emacs-zones-to-lift-you-up/ >> - RAM consumption grows to ~600Mb >> - R (redisplay page): RAM grows to ~1100Mb >> - R (redisplay page): RAM grows to ~1752Mb >> - R (redisplay page): RAM grows to ~2222Mb >> - rinse and repeat: RAM never goes down >> - (image-cache-size) reports a modest 82Mb >> - Kill buffer: high RAM consumption is still at its maximum, even >> after (image-cache-size) goes to 0 > > Run some utility that displays the memory-map of an application, and > you will see that most of that memory is free for use. Emacs just > didn't release it to the OS, but kept it in the memory pages allocated > to the process, for future allocations. then, why is the process not reusing that memory the second, third, etc. times i reload the exact same page, with the exact same images in the same buffer? if the first allocation reserved that memory and the process has it, after killing the buffer and opening the page again, it has plenty of free for use memory at its disposal, yet it allocates a fresh new block of 600Mb every time. with that behaviour, i just have to open 10 times the same page to run out of RAM in my computer. not even firefox is that hungry. > The strategy for releasing memory to the OS is in glibc, not under our > control. Last time we talked with glibc developers, they maintained > that this is the expected and correct behavior. well, all i can say is that none of the programs i use in my linux distribution (debian unstable), which are compiled against the same libraries, has shown such a dramatic increase of RAM consumption in the last months. so they seem to have optimized their allocation behaviour very narrowly against the way i use emacs! ;) perhaps i'll try to compile emacs using older gcc versions (up to version 27, emacs was really slim RAM-wise for me). thanks, jao From unknown Thu Aug 14 22:14:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#56546: 29.0.50; unbounded RAM comsumption when displaying images Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Jul 2022 17:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56546 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Jose A. Ortega Ruiz" Cc: 56546@debbugs.gnu.org Received: via spool by 56546-submit@debbugs.gnu.org id=B56546.165781797729493 (code B ref 56546); Thu, 14 Jul 2022 17:00:02 +0000 Received: (at 56546) by debbugs.gnu.org; 14 Jul 2022 16:59:37 +0000 Received: from localhost ([127.0.0.1]:38702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oC2Bc-0007fd-JP for submit@debbugs.gnu.org; Thu, 14 Jul 2022 12:59:36 -0400 Received: from quimby.gnus.org ([95.216.78.240]:36376) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oC2BZ-0007fO-0u for 56546@debbugs.gnu.org; Thu, 14 Jul 2022 12:59:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=r9jg3mPep+qIptaqpotudr7eiboLPuK1MkSsGiMriIw=; b=Z1y7bs5F1SZJYytDK3bqAHmlm5 iuTn/Y+OJhwf1MMRiEckBFJgmBZCgtXEiqL1vzBRDfNrUIuewrHbx+Ge7B2ekBOCh3TysLKHvDVV8 fb+23H9wjUelHQFMxYRZW+v+vf+Wn7BaU8RcoqaTLhZEQhHtdhrHgN05wBCfwlMgtJyc=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oC2BP-0004RS-6k; Thu, 14 Jul 2022 18:59:25 +0200 From: Lars Ingebrigtsen In-Reply-To: <87cze84gst.fsf@mail.jao.io> (Jose A. Ortega Ruiz's message of "Thu, 14 Jul 2022 02:35:46 +0100") References: <87cze84gst.fsf@mail.jao.io> X-Now-Playing: Aoki Tomonori + Mochizuki Harutaka + Kawabata Makoto - Pink Lady Lemonade's _Being for the Benefit of =?UTF-8?Q?Kaf=C3=A9_?= =?UTF-8?Q?H=C3=A6rverk!=5F:?= "Chaotic Dark Splash" Date: Thu, 14 Jul 2022 18:59:20 +0200 Message-ID: <874jzjbpg7.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: "Jose A. Ortega Ruiz" writes: > - emacs -Q > - M-x eww RET https://xenodium.com/emacs-zones-to-lift-you-up/ > - RAM consumption grows to ~600Mb > - R (redisplay page): RAM grows to ~1100Mb > - R (redisplay page): RAM grows to ~175 [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) "Jose A. Ortega Ruiz" writes: > - emacs -Q > - M-x eww RET https://xenodium.com/emacs-zones-to-lift-you-up/ > - RAM consumption grows to ~600Mb > - R (redisplay page): RAM grows to ~1100Mb > - R (redisplay page): RAM grows to ~1752Mb > - R (redisplay page): RAM grows to ~2222Mb > - rinse and repeat: RAM never goes down > - (image-cache-size) reports a modest 82Mb > - Kill buffer: high RAM consumption is still at its maximum, even > after (image-cache-size) goes to 0 I think this should all be fixed on the current trunk now -- can you check? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Thu Aug 14 22:14:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#56546: 29.0.50; unbounded RAM comsumption when displaying images Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Jul 2022 17:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56546 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: mail@jao.io, 56546@debbugs.gnu.org Received: via spool by 56546-submit@debbugs.gnu.org id=B56546.16578195868161 (code B ref 56546); Thu, 14 Jul 2022 17:27:01 +0000 Received: (at 56546) by debbugs.gnu.org; 14 Jul 2022 17:26:26 +0000 Received: from localhost ([127.0.0.1]:38751 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oC2ba-00027Z-2V for submit@debbugs.gnu.org; Thu, 14 Jul 2022 13:26:26 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37510) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oC2bU-00027F-Ve for 56546@debbugs.gnu.org; Thu, 14 Jul 2022 13:26:24 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47560) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oC2bP-0006bE-Ho; Thu, 14 Jul 2022 13:26:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=GqFPchFICB+t3gp89HPrYpkS1wAgSdFcEijZ8iOPUFw=; b=mJZxgLKEN4V3 pZARvSeQ+EwAkZvc72nfp06y0pmGo54G6R1X27LkPMusO/y6hdhy8CqtNY+x307QiWrnzPXqzaGM1 YTKJ3gS49aorhkOXcxQrd7d0x979leGF4LiEu5h5A1MVOS6bKmraFyKb4KCTMms787DYH9eOC5YmD Gmd7d5Fx4JvHZ0+BMiXWToqZOLg/BwJdidozPTbHjvCEI2Uc7Tea5/gLUpX3+aUU1yPQxUk+p+MGX ziMpn7XPVQooI6+qC5WUdUXYxvh0Cb39fMd1ZnjsFTY9xLygpGCA3195ZD9NjA+P8jp5C7SwPkclk 3SjBfqvBdODKfZiCwgLGsw==; Received: from [87.69.77.57] (port=4280 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oC2bO-0001w1-W8; Thu, 14 Jul 2022 13:26:15 -0400 Date: Thu, 14 Jul 2022 20:26:09 +0300 Message-Id: <83zghbsj0u.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <874jzjbpg7.fsf@gnus.org> (message from Lars Ingebrigtsen on Thu, 14 Jul 2022 18:59:20 +0200) References: <87cze84gst.fsf@mail.jao.io> <874jzjbpg7.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 56546@debbugs.gnu.org > From: Lars Ingebrigtsen > Date: Thu, 14 Jul 2022 18:59:20 +0200 > > "Jose A. Ortega Ruiz" writes: > > > - emacs -Q > > - M-x eww RET https://xenodium.com/emacs-zones-to-lift-you-up/ > > - RAM consumption grows to ~600Mb > > - R (redisplay page): RAM grows to ~1100Mb > > - R (redisplay page): RAM grows to ~1752Mb > > - R (redisplay page): RAM grows to ~2222Mb > > - rinse and repeat: RAM never goes down > > - (image-cache-size) reports a modest 82Mb > > - Kill buffer: high RAM consumption is still at its maximum, even > > after (image-cache-size) goes to 0 > > I think this should all be fixed on the current trunk now -- can you > check? FWIW, on my system the pattern of the memory footprint didn't change after this. I still see the footprint going up after each "M-x eww", and killing the buffer and invoking clear-image-cache causes Emacs to go back to somewhat higher than its original size. From unknown Thu Aug 14 22:14:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#56546: 29.0.50; unbounded RAM comsumption when displaying images Resent-From: Glenn Morris Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Jul 2022 17:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56546 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: "Jose A. Ortega Ruiz" , 56546@debbugs.gnu.org Received: via spool by 56546-submit@debbugs.gnu.org id=B56546.165782108019298 (code B ref 56546); Thu, 14 Jul 2022 17:52:01 +0000 Received: (at 56546) by debbugs.gnu.org; 14 Jul 2022 17:51:20 +0000 Received: from localhost ([127.0.0.1]:38819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oC2zg-00051C-Ig for submit@debbugs.gnu.org; Thu, 14 Jul 2022 13:51:20 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42306) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oC2zf-00050z-0Z for 56546@debbugs.gnu.org; Thu, 14 Jul 2022 13:51:19 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47696) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oC2zY-0004fV-17; Thu, 14 Jul 2022 13:51:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=2JkMDTvQmI8d0TK/e/gBbyqsdvrJiB7yOCVeYoCZQQM=; b=mQnnaOvqUbp9BDEGmDZr 7gHfUzJoZ8HAsgovrEuWbErAmYtRtE1ijY8GbEmpAbzbCT+vQrz6wF8pfXUhIwvtRYcpRozTXCU8r Y4XXt312Y9MAdq3YLvS+uWDiCatV+O6Khv+zKLM0haHVeLe20MyenbI4xijctJpKre8edzfV8iKry u6fWYQT/1Bav7UmiCXkcm9Swa75DgjmG4Yq2Rzcj5rLLicmLSO2MyvTgjOrD6voYcpHeD8VedkbMC rcrpByBl3Y1OBD4UX+Vb8ZBOfxW5DEIoQTKtvcWHovEapksWJGUbgScW/uwGf3eCrMEVUiwkDQpph 4lmvngJONz+YsA==; Received: from rgm by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1oC2zV-0006hg-5J; Thu, 14 Jul 2022 13:51:11 -0400 From: Glenn Morris References: <87cze84gst.fsf@mail.jao.io> <874jzjbpg7.fsf@gnus.org> X-Spook: Conficker Khaddafi Public Health Shelter-in-place X-Ran: ^\)LLUizkwz#ltyd>;]*vzePa\E,I.u3IOw1x4W^).BX (Lars Ingebrigtsen's message of "Thu, 14 Jul 2022 18:59:20 +0200") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 564f6c breaks --without-all --without-x builds. Ref eg https://hydra.nixos.org/build/183877918 From unknown Thu Aug 14 22:14:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#56546: 29.0.50; unbounded RAM comsumption when displaying images Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Jul 2022 18:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56546 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Glenn Morris Cc: "Jose A. Ortega Ruiz" , 56546@debbugs.gnu.org Received: via spool by 56546-submit@debbugs.gnu.org id=B56546.165782209429294 (code B ref 56546); Thu, 14 Jul 2022 18:09:02 +0000 Received: (at 56546) by debbugs.gnu.org; 14 Jul 2022 18:08:14 +0000 Received: from localhost ([127.0.0.1]:38846 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oC3G2-0007cO-Gl for submit@debbugs.gnu.org; Thu, 14 Jul 2022 14:08:14 -0400 Received: from quimby.gnus.org ([95.216.78.240]:37372) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oC3G0-0007cB-1A for 56546@debbugs.gnu.org; Thu, 14 Jul 2022 14:08:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=q/p37wkYCgIW5GD/+FBq+xOwRoq+kmv9Ez5EKuk8UGQ=; b=nrFX3u313zmtTs2VNWq3ewFvpj P1hE28IuH4kGuqo+z9FRFp8MrGSks4wBoKltNV1hgynQL3IEc4ykywwbm+GuvcDvCekYKEHjChcIe hV+ahxKBHCkkItJWhGigRZbI32TmbEzloo6pYD/eRw5agRU7CVE+NSYoZcP9vfY8VGa4=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oC3Fq-00057H-Vk; Thu, 14 Jul 2022 20:08:05 +0200 From: Lars Ingebrigtsen In-Reply-To: (Glenn Morris's message of "Thu, 14 Jul 2022 13:51:09 -0400") References: <87cze84gst.fsf@mail.jao.io> <874jzjbpg7.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAFVBMVEXk284dFxavnJOM dm5bQz6Yg3v///+dUZfgAAAAAWJLR0QGYWa4fQAAAAd0SU1FB+YHDhIDOTW8VckAAAGbSURBVDjL lZO7dsIwDIZd2gfAwd1bE+8lUva6FjuHJO//KtXFhgBlqBZz9EW3X8I59+If7MOJfT6Cr2dgqyA/ gvdnIDwDXsEffm1rs3a06K8VyOQ9ARj6ZvAqP3bZw7BQ9oFy6/dNuiAfjjEihRxQQFeBshhhgH6I ErJzJhWFeYBzZFuiglDBSOo1O9RBWKoQ9+MdOJmG5tnYk2u/8sEqUQVbk+pn5d8r2Bk4iqOBpq8+ 7Ei1xtz01WeQiE0SQBWYhpyr/0l0Yn4LgnhISmEDrwYkV5FME1ZgGoYio6RpvBZvYCI2CTzcAK6O BYH9qW63nVuJCUbgdD3dgsA1VDG8A02umcgrcn07vkGFIkJuQsC+nZROgaEAwcizuPlybIMU4MuC 5cw7uaSSWdhfRhmSl2IgtxMiWJZFhTFQO5EAaw7J2s3aCQcUgGk8x4Sgm+WDzcLqbB1vM7qa+yAD lBAEdpLMESDnzv1MPR4LEd/9uwLZMuuNSDOyPzDoGkgmnP01gr+CuAfkgWGcYLrcsLMn3RzpGgxP wKP9H/wCro6L3ezBcMcAAAAldEVYdGRhdGU6Y3JlYXRlADIwMjItMDctMTRUMTg6MDM6NTcrMDA6 MDCaGRoPAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIyLTA3LTE0VDE4OjAzOjU3KzAwOjAw60SiswAA AABJRU5ErkJggg== X-Now-Playing: Heidi Berry's _Miracle_: "Darkness, Darkness" Date: Thu, 14 Jul 2022 20:08:02 +0200 Message-ID: <87cze77ekd.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Glenn Morris writes: > 564f6c breaks --without-all --without-x builds. > Ref eg https://hydra.nixos.org/build/183877918 Yup. Now fixed. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Glenn Morris writes: > 564f6c breaks --without-all --without-x builds. > Ref eg https://hydra.nixos.org/build/183877918 Yup. Now fixed. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Thu Aug 14 22:14:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#56546: 29.0.50; unbounded RAM comsumption when displaying images Resent-From: "Jose A. Ortega Ruiz" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 Jul 2022 23:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56546 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: 56546@debbugs.gnu.org Received: via spool by 56546-submit@debbugs.gnu.org id=B56546.165792854719820 (code B ref 56546); Fri, 15 Jul 2022 23:43:01 +0000 Received: (at 56546) by debbugs.gnu.org; 15 Jul 2022 23:42:27 +0000 Received: from localhost ([127.0.0.1]:42396 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oCUx1-00059c-7P for submit@debbugs.gnu.org; Fri, 15 Jul 2022 19:42:27 -0400 Received: from relay11.mail.gandi.net ([217.70.178.231]:48459) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oCUwy-00059O-Tu for 56546@debbugs.gnu.org; Fri, 15 Jul 2022 19:42:25 -0400 Received: (Authenticated sender: mail@jao.io) by mail.gandi.net (Postfix) with ESMTPSA id B9CE4100004; Fri, 15 Jul 2022 23:42:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jao.io; s=gm1; t=1657928538; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XWMfLbIgArugcqsBb1ZK6MyFKYxarbTOI78h+29+Kms=; b=erSh0BMN/KdfH1ja4M7pzYqEaESPQLmqNGGYDj9rkTeF9gu5EdXs1ZlEG6ntGXQSEIlcuF 6BRKNuzhmyHZw9rA60Md0gTYJ9+3ACP9OAWQWiRv5WwO/o182et/JKLV0KGERtUe7tMUeI BYyY7Mw9RqKQ62hD5ccduubTwbR5MWBfmI2g2Jb7b7McAQqkab81YzC1GojHfB4tAF2Sih D6FmrweYEvE0M49LyULNtql0wrZXhbPtsfmbUaZh9Z7d7MsKttVt2nYZLKY05ieWQ17d5h F2woEQMNlMqD2Lr/Ab3Vop0ZijZBb5KDzkkCl3Kck2hrWNKbuPyf+juC42lH0A== Received: from localhost (rivendell.localdomain [local]) by rivendell.localdomain (OpenSMTPD) with ESMTPA id fd8013be; Fri, 15 Jul 2022 23:42:16 +0000 (UTC) From: "Jose A. Ortega Ruiz" In-Reply-To: <874jzjbpg7.fsf@gnus.org> (Lars Ingebrigtsen's message of "Thu, 14 Jul 2022 18:59:20 +0200") References: <87cze84gst.fsf@mail.jao.io> <874jzjbpg7.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) X-Attribution: jao X-Clacks-Overhead: GNU Terry Pratchett X-URL: Date: Sat, 16 Jul 2022 00:42:16 +0100 Message-ID: <87r12mhrjb.fsf@mail.jao.io> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On Thu, Jul 14 2022, Lars Ingebrigtsen wrote: > "Jose A. Ortega Ruiz" writes: > >> - emacs -Q >> - M-x eww RET https://xenodium.com/emacs-zones-to-lift-you-up/ >> - RAM consumption grows to ~600Mb >> - R (redisplay page): RAM grows to ~1100Mb >> - R (redisplay page): RAM grows to ~1752Mb >> - R (redisplay page): RAM grows to ~2222Mb >> - rinse and repeat: RAM never goes down >> - (image-cache-size) reports a modest 82Mb >> - Kill buffer: high RAM consumption is still at its maximum, even >> after (image-cache-size) goes to 0 > > I think this should all be fixed on the current trunk now -- can you > check? Yes, it essentially does. Only the first jump to ~630Mb happens, and then memory stays there after repeated reloads. If i do it often (or quickly, i think) enough i can make it occasionally jump to the ~1200Mb mark, but for instance cleaning the image cache makes it go back to ~600Mb (so there are clearly situations where big chunks of memory do get released back to the system, thankfully). So i think you did fix the problem, thanks a lot Lars! While we're here, i was inspecting the image-cache-size during the reloads of the page, and i saw every reload increases that size by about 30Mb (then it will eventually go down as old images are released)... given that, the big initial jump of ~500Mb in RAM consumption surprises me a little, but i see reasons why it can be completely normal for some initial allocation (and how it might be staying there because of libgcc policies). I was also naively expecting that, given that i'm reloading the same page with the "same" images, they'd be found in the cache the second and subsequent times, but, since the cache size increases, i see that they're not considered the "same" by the caching mechanism; i can again see reasons for that behaviour (i am sure the cache is not judging image equality using "image urls"), just mentioning it in case it's unexpected or there's an easy way of reusing the cached images). Anyway, thanks a lot for bearing with me and solving the problem: this bug is all but fixed now from my point of view. Cheers, jao -- That's a high price to pay for a theoretically inelegant misfeature that's seldom used correctly in portable code. -Will Clinger, r6rs-discuss mailing list From unknown Thu Aug 14 22:14:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#56546: 29.0.50; unbounded RAM comsumption when displaying images Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Jul 2022 10:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56546 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Jose A. Ortega Ruiz" Cc: 56546@debbugs.gnu.org Received: via spool by 56546-submit@debbugs.gnu.org id=B56546.16579678891564 (code B ref 56546); Sat, 16 Jul 2022 10:39:02 +0000 Received: (at 56546) by debbugs.gnu.org; 16 Jul 2022 10:38:09 +0000 Received: from localhost ([127.0.0.1]:43003 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oCfBZ-0000PA-AP for submit@debbugs.gnu.org; Sat, 16 Jul 2022 06:38:09 -0400 Received: from quimby.gnus.org ([95.216.78.240]:56096) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oCfBX-0000Ow-MO for 56546@debbugs.gnu.org; Sat, 16 Jul 2022 06:38:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=5A4Ed4nqIngpMqXKyYaOKqpTmXfKLGWQznXbgpIZ1LM=; b=ODiD0Rl1kAH2V4I7AK4gpENncd OlRmewmqrHJ8xsE5jKVVXZXO64BAhLicOAkcTJtyEfIyTrCw5d5Wmffc/UNFJiLxUFqR6QNCvpvFr OZVmX6q7QLvZ5Nqh98Up9jBXZB/ghDkj5tAfkW5ladtiPmQVUN48+lbKdC46qrsVDgOY=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oCfBO-0000zr-Tf; Sat, 16 Jul 2022 12:38:01 +0200 From: Lars Ingebrigtsen In-Reply-To: <87r12mhrjb.fsf@mail.jao.io> (Jose A. Ortega Ruiz's message of "Sat, 16 Jul 2022 00:42:16 +0100") References: <87cze84gst.fsf@mail.jao.io> <874jzjbpg7.fsf@gnus.org> <87r12mhrjb.fsf@mail.jao.io> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAFVBMVEVmX11rZWlUU2iD dmZRTlc4O1T///8ttQVxAAAAAWJLR0QGYWa4fQAAAAd0SU1FB+YHEAofMX/jUsIAAAGySURBVDjL bZKJjeAgDEU/VgqATAPGSgfbQBSRBlbQfyvrg1yjtZSE+OHvA5BQptWfVR4DpXBL+SkTkOgKqwNZ yx//PhE5QFV/LuURA5L91pknh1dXIBi4CijhVT+E08vvthZ1QqS+gaxVY4ShIbqeCSx36KgdSfhJ kGJDgUlRvf23IgSHgjpLTW8g975XCZk0goKky4+SM1zK6qszAD7rjLQqYG1yratlmkfgIObMsDa9 7uSgaIQIay6OLrSHQiANbj7OJPKM0pQyjmOeWmYdnfetE1dtDiA6Y9ixke0yEH722siOIOIxwQUp VqsBJ9X3AfO8Be8Iu0syoxT8fRF2l74OLeyg/wCO85C3WXEB+As8EuCP1B28K9h95X0x4b6fQNvp VSuRZVFAOD85GPkCDTewaiskukTHO8IT7WQR+y+gaXkxcA3uaZC23S/vF2zwq2F2Hl8QR6p9tAds cvDS7au9NxWc6TfdxMsYbW9bc7V2+CVqBs7RVaVNsLfbFLSmT+TfsQ21CUY/x9AGsXQs6hqt29us t6F6y5QYbZymcjrBpW0/p337CCnff3YH3QPD/gGqh4uOt56NmgAAACV0RVh0ZGF0ZTpjcmVhdGUA MjAyMi0wNy0xNlQxMDozMTo0OSswMDowMEY4If4AAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjItMDct MTZUMTA6MzE6NDkrMDA6MDA3ZZlCAAAAAElFTkSuQmCC X-Now-Playing: Xeno & Oaklander's _Sentinelle_: "4th Wall" Date: Sat, 16 Jul 2022 12:37:58 +0200 Message-ID: <87y1wts5q1.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: "Jose A. Ortega Ruiz" writes: > I was also naively expecting > that, given that i'm reloading the same page with the "same" images, > they'd be found in the cache the second and subsequent times, but, since > the cache size increa [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) "Jose A. Ortega Ruiz" writes: > I was also naively expecting > that, given that i'm reloading the same page with the "same" images, > they'd be found in the cache the second and subsequent times, but, since > the cache size increases, i see that they're not considered the "same" > by the caching mechanism; i can again see reasons for that behaviour (i > am sure the cache is not judging image equality using "image urls"), > just mentioning it in case it's unexpected or there's an easy way of > reusing the cached images). >From Emacs' point of view, these aren't "the same", because they're not taken (directly) from files, I think. > Anyway, thanks a lot for bearing with me and solving the problem: this > bug is all but fixed now from my point of view. Thanks for checking; I'm closing this bug report, then. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 16 06:38:17 2022 Received: (at control) by debbugs.gnu.org; 16 Jul 2022 10:38:18 +0000 Received: from localhost ([127.0.0.1]:43006 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oCfBh-0000PW-N6 for submit@debbugs.gnu.org; Sat, 16 Jul 2022 06:38:17 -0400 Received: from quimby.gnus.org ([95.216.78.240]:56110) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oCfBf-0000PK-Lz for control@debbugs.gnu.org; Sat, 16 Jul 2022 06:38:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=k4cYSDy/WdzYVE2eEn+aUL2xrcjH2YX3qQzaISuwVRI=; b=eIpGHu4uooM1sSPl+MlkbCBesr yCzMYRxWs4JGAq7VcEt5i1sPWYEgcGz1o6j1K4d5bsewnk7qtEmRuusgviCapfa203t0ZPCgTpqpp dZDHswY8W/RWZDouzt9dgUBkSvuf4BgxuaQBiWa2jLHi5mrtY8DKra97qNp/m79ypNeE=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oCfBX-000104-Ti for control@debbugs.gnu.org; Sat, 16 Jul 2022 12:38:09 +0200 Date: Sat, 16 Jul 2022 12:38:07 +0200 Message-Id: <87wncds5ps.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #56546 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 56546 29.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control 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 (---) close 56546 29.1 quit