GNU bug report logs -
#34320
Emacs 26.1: RAM does not get released after quitting Emacs
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 34320 in the body.
You can then email your comments to 34320 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34320
; Package
emacs
.
(Mon, 04 Feb 2019 21:11:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
René Kuligowski <renekuligowski <at> o2mail.de>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 04 Feb 2019 21:11:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34320
; Package
emacs
.
(Mon, 04 Feb 2019 23:49:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 34320 <at> debbugs.gnu.org (full text, mbox):
Either the process hasn't actually exited, or you are confused by memory
used for file cache. Ref eg https://www.linuxatemyram.com/
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34320
; Package
emacs
.
(Tue, 05 Feb 2019 16:02:12 GMT)
Full text and
rfc822 format available.
Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
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 <at> o2mail.de>
To: Glenn Morris <rgm <at> 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/
>
>
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34320
; Package
emacs
.
(Tue, 05 Feb 2019 17:22:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 34320 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 05 Feb 2019 11:45:29 -0100
> From: René Kuligowski <renekuligowski <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34320
; Package
emacs
.
(Wed, 06 Feb 2019 19:43:02 GMT)
Full text and
rfc822 format available.
Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):
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 <at> 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?
>
>
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34320
; Package
emacs
.
(Wed, 06 Feb 2019 20:20:02 GMT)
Full text and
rfc822 format available.
Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34320
; Package
emacs
.
(Wed, 20 Feb 2019 19:16:01 GMT)
Full text and
rfc822 format available.
Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34320
; Package
emacs
.
(Wed, 20 Feb 2019 19:31:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 34320 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 20 Feb 2019 20:19:41 -0100
> From: René Kuligowski <renekuligowski <at> 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.
Added tag(s) wontfix and notabug.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Tue, 26 Feb 2019 02:54:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
34320 <at> debbugs.gnu.org and René Kuligowski <renekuligowski <at> o2mail.de>
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Tue, 26 Feb 2019 02:54:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 26 Mar 2019 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 25 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.