GNU bug report logs - #56546
29.0.50; unbounded RAM comsumption when displaying images

Previous Next

Full log

Message #11 received at 56546 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: mail <at> jao.io
Cc: 56546 <at> debbugs.gnu.org
Subject: Re: bug#56546: 29.0.50;
 unbounded RAM comsumption when displaying images
Date: Thu, 14 Jul 2022 09:04:51 +0300

> Cc: 56546 <at> debbugs.gnu.org
> Date: Thu, 14 Jul 2022 08:45:24 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: "Jose A. Ortega Ruiz" <mail <at> jao.io>
> > 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"?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.