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

Previous Next

Full log

Message #32 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 20:18:17 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 33275 <at> debbugs.gnu.org
> Date: Mon, 05 Nov 2018 18:36:39 +0100
> 
> It would be reasonable if the code had asked for those images to be kept
> in memory, but it hasn't.  Emacs decides that on its own without saying
> that it's doing that.

You cannot assume anything about memory management while a Lisp
program runs.

> It'd be similarly surprising if
> 
> (dolist (file (directory-files "/directory/with/many/images" t "png$"))
>   (with-temp-buffer
>     (insert-file-contents-literally file)))
> 
> were to lead to Emacs growing uncontrollably.

That it doesn't is just sheer luck: the way we manage buffer memory is
special.  With any other Lisp object, it could well grow
uncontrollably.  Our way of keeping that in check is to signal
memory-full error when we are about to run out of memory.  Not sure
yet why this doesn't happen in your original recipe.

> > 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?
> 
> Sorry, I'm not familiar with the memory_full stuff...

OK, I will try to look into this soon.

Previous Next

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