* bug#34320: Emacs 26.1: RAM does not get released after quitting Emacs
@ 2019-02-04 21:32 René Kuligowski
2019-02-04 23:48 ` Glenn Morris
` (3 more replies)
0 siblings, 4 replies; 8+ messages in thread
From: René Kuligowski @ 2019-02-04 21:32 UTC (permalink / raw)
To: 34320
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#34320: Emacs 26.1: RAM does not get released after quitting Emacs
2019-02-04 21:32 bug#34320: Emacs 26.1: RAM does not get released after quitting Emacs René Kuligowski
@ 2019-02-04 23:48 ` Glenn Morris
2019-02-05 12:45 ` bug#34320: Fwd: " René Kuligowski
` (2 subsequent siblings)
3 siblings, 0 replies; 8+ messages in thread
From: Glenn Morris @ 2019-02-04 23:48 UTC (permalink / raw)
To: René Kuligowski; +Cc: 34320
Either the process hasn't actually exited, or you are confused by memory
used for file cache. Ref eg https://www.linuxatemyram.com/
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#34320: Fwd: Re: bug#34320: Emacs 26.1: RAM does not get released after quitting Emacs
2019-02-04 21:32 bug#34320: Emacs 26.1: RAM does not get released after quitting Emacs René Kuligowski
2019-02-04 23:48 ` Glenn Morris
@ 2019-02-05 12:45 ` René Kuligowski
2019-02-05 17:20 ` Eli Zaretskii
2019-02-06 22:22 ` René Kuligowski
2019-02-20 21:19 ` René Kuligowski
3 siblings, 1 reply; 8+ messages in thread
From: René Kuligowski @ 2019-02-05 12:45 UTC (permalink / raw)
To: 34320
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/
>
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#34320: Fwd: Re: bug#34320: Emacs 26.1: RAM does not get released after quitting Emacs
2019-02-05 12:45 ` bug#34320: Fwd: " René Kuligowski
@ 2019-02-05 17:20 ` Eli Zaretskii
2019-02-06 21:46 ` René Kuligowski
0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2019-02-05 17:20 UTC (permalink / raw)
To: René Kuligowski; +Cc: 34320
> 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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#34320: Fwd: Re: bug#34320: Emacs 26.1: RAM does not get released after quitting Emacs
2019-02-05 17:20 ` Eli Zaretskii
@ 2019-02-06 21:46 ` René Kuligowski
0 siblings, 0 replies; 8+ messages in thread
From: René Kuligowski @ 2019-02-06 21:46 UTC (permalink / raw)
To: eliz, 34320
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?
>
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#34320: Emacs 26.1: RAM does not get released after quitting Emacs
2019-02-04 21:32 bug#34320: Emacs 26.1: RAM does not get released after quitting Emacs René Kuligowski
2019-02-04 23:48 ` Glenn Morris
2019-02-05 12:45 ` bug#34320: Fwd: " René Kuligowski
@ 2019-02-06 22:22 ` René Kuligowski
2019-02-20 21:19 ` René Kuligowski
3 siblings, 0 replies; 8+ messages in thread
From: René Kuligowski @ 2019-02-06 22:22 UTC (permalink / raw)
To: eliz, 34320
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#34320: Emacs 26.1: RAM does not get released after quitting Emacs
2019-02-04 21:32 bug#34320: Emacs 26.1: RAM does not get released after quitting Emacs René Kuligowski
` (2 preceding siblings ...)
2019-02-06 22:22 ` René Kuligowski
@ 2019-02-20 21:19 ` René Kuligowski
2019-02-20 19:30 ` Eli Zaretskii
3 siblings, 1 reply; 8+ messages in thread
From: René Kuligowski @ 2019-02-20 21:19 UTC (permalink / raw)
To: 34320
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#34320: Emacs 26.1: RAM does not get released after quitting Emacs
2019-02-20 21:19 ` René Kuligowski
@ 2019-02-20 19:30 ` Eli Zaretskii
0 siblings, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2019-02-20 19:30 UTC (permalink / raw)
To: René Kuligowski; +Cc: 34320
> 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-02-20 21:19 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-02-04 21:32 bug#34320: Emacs 26.1: RAM does not get released after quitting Emacs René Kuligowski
2019-02-04 23:48 ` Glenn Morris
2019-02-05 12:45 ` bug#34320: Fwd: " René Kuligowski
2019-02-05 17:20 ` Eli Zaretskii
2019-02-06 21:46 ` René Kuligowski
2019-02-06 22:22 ` René Kuligowski
2019-02-20 21:19 ` René Kuligowski
2019-02-20 19:30 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.