GNU bug report logs - #33275
27.0.50; Image cache pruning

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 33275 <at> debbugs.gnu.org
Subject: Re: bug#33275: 27.0.50; Image cache pruning
Date: Mon, 05 Nov 2018 19:27:28 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 33275 <at> debbugs.gnu.org
> Date: Mon, 05 Nov 2018 17:35:51 +0100
> 
> >> If you visit a, say, 16GB file, then, indeed, it's expected that Emacs
> >> grows to 16GB (or more).  But if you're just calling `image-size' on a
> >> bunch of files (each of which is a lot smaller than that), it's rather
> >> unexpected that that's going to blow up Emacs.
> >
> > What was the sum of sizes of all the files you used to reproduce the
> > problem?
> 
> I think it's sufficient to run Emacs over 2GB worth of .png files to
> make Emacs grow to 16GB (which will kill it on this laptop).
> 
> But it'll vary on how well-compressed the .png files are, I guess,
> because I think Emacs caches the, er, pixmaps and not the files?  I
> don't remember.

I think it's reasonable to expect 2GB worth of image files to take
several times that in memory.  (Btw, visiting a 16GB file usually
takes twice that much during insert-file-contents.)

I think we should try to add some code that would call
display_malloc_warning and/or memory_full, before the system runs out
of memory.  That should be enough to prevent OOM in such cases.  Can
you spot why we never called memory_full in this case?

Previous Next

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