bug#34320: Emacs 26.1: RAM does not get released after quitting Emacs

bug#34320: Emacs 26.1: RAM does not get released after quitting Emacs

[René Kuligowski]

Good morning,

I just noticed something which I thought might be interesting, and which 
I stumbled across by watching my conky window's memory watcher (issuing 
'free' and 'vmstat' on the console always says the same as conky, so I 
guess it does update correctly).

The Story And What Happens (to indirectly quote Terry Pratchett):
Whenever I run Emacs 26.1 (Lucid X interface) and it loads its package 
configuration, it quickly allocates about 300 to 400 MB of RAM, and when 
I use several Emacs modi (org, auctex, etc), it tends to allocate about 
700 MB in total.  Accumulated on top of my average system load, the used 
memory rapidly goes from 520MB to 1.2 GB just due to Emacs.  When I quit 
Emacs, the used RAM does only drop back to about 1.1 to 1.0 GB, not to, 
say, 600MB as I would expect (and as Emacs 23 and 25 do – well, Emacs 25 
doesn't release all memory, either, but leaves only an after-print of, 
say, 30 MB, not 400).  And even several hours later with nothing running 
except for the wm (fvwm, if you want to know), conky and a screen saver 
the memory is not released, so I presume it is not caused by the 
caching/preemptivity mechanisms of the system kernel or the library loader.

Is this behaviour perhaps due to Emacs's code being aligned to modern C 
compilers, libraries, and bloated system configurations?  Perhaps, even, 
due to yours concentrating on GTK3 as X UI?  I am asking this because I 
run a debian 6 system, with GCC 4.x, GTK2 (which I do not use, if 
possible), without servicesd or systemd and with somewhat older memory 
management libraries.

Can this be resolved on your side, or is there a trick I can use, except 
for re-starting my whole system?

Regards,
R.Kuligowski

bug#34320: Emacs 26.1: RAM does not get released after quitting Emacs

[Glenn Morris]

Either the process hasn't actually exited, or you are confused by memory
used for file cache. Ref eg https://www.linuxatemyram.com/

bug#34320: Fwd: Re: bug#34320: Emacs 26.1: RAM does not get released after quitting Emacs

[René Kuligowski]

For completeness ;-)

   I also checked thoroughly in the VFSes (/sys, /proc etc.) and ran a 
mem tracer.  The memory blocks are not freed, but stay allocated, like 
from a forgotten free() call or a severely buggy malloc() call (like the 
common issues with gcc 3.3 and 4.5).

   Since I use gcc 4.4 (quite reliable in my experience), my question 
is: is Emacs 26 using mem alloc calls which are revised/defined in 
C-2011 or C-2015 standards, and not likely to be properly available in 
older compilers?  That might be an explanation, though not exactly the 
„cure“ for the problem.

Regards,
R.Kuligowski

-------- Original Message --------
Subject: 	Re: bug#34320: Emacs 26.1: RAM does not get released after 
quitting Emacs
Date: 	Tue, 05 Feb 2019 07:34:10 -0100
From: 	René Kuligowski <renekuligowski@o2mail.de>
To: 	Glenn Morris <rgm@gnu.org>



Sorry, the last answer was a bit short.
Reasons why neither is the case:

doing 'ps axf | grep emacs' shows only the grep call itself.  Without
grepping, there is no hint of either emacs or a died/zombie process
eating up memory.

the '+/- cache' line of free shows the amounts I stated, the first one
is always about 1GB larger due to cache buffers.

On 04.02.2019 22:48, Glenn Morris wrote:
>  Either the process hasn't actually exited, or you are confused by memory
>  used for file cache. Ref eg https://www.linuxatemyram.com/
>
>
>

bug#34320: Fwd: Re: bug#34320: Emacs 26.1: RAM does not get released after quitting Emacs

[Eli Zaretskii]

> Date: Tue, 05 Feb 2019 11:45:29 -0100
> From: René Kuligowski <renekuligowski@o2mail.de>
> 
>    I also checked thoroughly in the VFSes (/sys, /proc etc.) and ran a 
> mem tracer.  The memory blocks are not freed, but stay allocated, like 
> from a forgotten free() call or a severely buggy malloc() call (like the 
> common issues with gcc 3.3 and 4.5).

Can you see which software module "owns" the memory that is not freed?
Could it be, for instance, that Emacs loaded some system shared
libraries, and the OS didn't unload them?

bug#34320: Fwd: Re: bug#34320: Emacs 26.1: RAM does not get released after quitting Emacs

[René Kuligowski]

Hmm… let me take another look… as far as I can tell, there's no 
recognizable owner to those, and ld seems not to be involved here — it 
shows with a big batch of libs, but not in the blocks in question, and 
most of them are not used by Emacs, afaik from the configure options and 
makefiles (but don't take my word for it, I'm not one of you Emacs 
developers ;-) ).  Looks more like a zombie without a zombie process to 
me, sort of like 'kill -9' successful but for some weird reason the 
memory being detached and not freed.  Can this happen with 
multi-threading, when the current thread's parent quits and somehow the 
child cannot cleanly exit?

   However, I'll try a few more methods, to find out as much as I can.  
Might take one or the other day, though.


Thanks so far!


On 05.02.2019 16:20, Eli Zaretskii wrote:
>> Date: Tue, 05 Feb 2019 11:45:29 -0100
>> From: René Kuligowski<renekuligowski@o2mail.de>
>>
>>     I also checked thoroughly in the VFSes (/sys, /proc etc.) and ran a
>> mem tracer.  The memory blocks are not freed, but stay allocated, like
>> from a forgotten free() call or a severely buggy malloc() call (like the
>> common issues with gcc 3.3 and 4.5).
>>      
> Can you see which software module "owns" the memory that is not freed?
> Could it be, for instance, that Emacs loaded some system shared
> libraries, and the OS didn't unload them?
>
>
>    

bug#34320: Emacs 26.1: RAM does not get released after quitting Emacs

[René Kuligowski]

Sorry for flooding, but I really forgot to state something more clearly 
which might be important in regard to the question whether the problems 
might be caused by library and/or general caching:

I have a parallel installation of Emacs 23 (this distro's standard 
Emacs), Emacs 25, and Emacs 26, the latter two being configured with the 
same compilation options (--prefix=/usr/local --with-x 
--with-x-toolkit=lucid --with-modules --without-tls 
--with-game-user=games) and using (almost) identical ELisp 
configurations, which means, all three use the same libraries, the same 
binary utilities, and the same ELisp where compatible.
   Those memory problems are /only/ with Emacs 26, /not/ with 25 or 23.  
Hence my strange questions and assumptions about the malloc()/free() and 
C standards used in 26.
I hope this helps.  And I'll still search for more clues to what causes 
this ;-)

Regards,
R. Kuligowski

bug#34320: Emacs 26.1: RAM does not get released after quitting Emacs

[Eli Zaretskii]

> Date: Wed, 20 Feb 2019 20:19:41 -0100
> From: René Kuligowski <renekuligowski@o2mail.de>
> 
> Sorry, had little time to spare for testing and research the problems, 
> hence it took a while ;-)

We all get hit by that from time to time ;-)

>    I guess my system is just too old for Emacs 26 and the upcoming 27.
>    But it would still be nice if one of you could further look into the 
> memory eating problem; maybe there is a solution (like, eg, ifdef-ing 
> other memory handling for older systems).

Whatever this is, it isn't Emacs that's causing this.  There simply is
no way a program could still hold onto memory after it exits.
Whatever doesn't let that memory be released it isn't Emacs, at least
not directly.

bug#34320: Emacs 26.1: RAM does not get released after quitting Emacs

[René Kuligowski]

Sorry, had little time to spare for testing and research the problems, 
hence it took a while ;-)

   However — and referring to my last mail —, I can safely conclude that 
the memory problems are not caused by any of: OS memory manager, OS 
library loader, Lucid toolkit version, GNU compiler/GClib, or fvwm (my 
X11 window manager), since the versions I use are not known to cause any 
problems.
   I guess my system is just too old for Emacs 26 and the upcoming 27.
   But it would still be nice if one of you could further look into the 
memory eating problem; maybe there is a solution (like, eg, ifdef-ing 
other memory handling for older systems).

Thanks and best regards,
R. Kuligowski