From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Jose A. Ortega Ruiz" Newsgroups: gmane.emacs.bugs Subject: bug#56546: 29.0.50; unbounded RAM comsumption when displaying images Date: Thu, 14 Jul 2022 13:23:01 +0100 Message-ID: <87h73j3mu2.fsf@mail.jao.io> References: <87cze84gst.fsf@mail.jao.io> <8335f4uu17.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6739"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 56546@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jul 14 14:24:12 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oBxt5-0001Z0-Ht for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 14 Jul 2022 14:24:11 +0200 Original-Received: from localhost ([::1]:45708 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oBxt4-0002cc-4V for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 14 Jul 2022 08:24:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59786) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBxsw-0002cB-Nj for bug-gnu-emacs@gnu.org; Thu, 14 Jul 2022 08:24:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55175) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oBxsw-00079s-FH for bug-gnu-emacs@gnu.org; Thu, 14 Jul 2022 08:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oBxsw-0002wQ-Aq for bug-gnu-emacs@gnu.org; Thu, 14 Jul 2022 08:24:02 -0400 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 56546-submit@debbugs.gnu.org id=B56546.165780139311158 (code B ref 56546); Thu, 14 Jul 2022 12:24:02 +0000 Original-Received: (at 56546) by debbugs.gnu.org; 14 Jul 2022 12:23:13 +0000 Original-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 Original-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 Original-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== Original-Received: from localhost (rivendell.localdomain [local]) by rivendell.localdomain (OpenSMTPD) with ESMTPA id 90b99f9a; Thu, 14 Jul 2022 12:23:01 +0000 (UTC) In-Reply-To: <8335f4uu17.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 14 Jul 2022 08:45:24 +0300") X-Attribution: jao X-Clacks-Overhead: GNU Terry Pratchett X-URL: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:236986 Archived-At: 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