In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.14.8, Xaw3d scroll bars)
of 2020-11-14 built on protected.rcdrun.com
Repository revision: 31f94e4b1c3dc201646ec436d3e2c477f784ed21
Repository branch: master
System Description: Hyperbola GNU/Linux-libre
value of $LC_ALL: en_US.UTF-8
value of $LANG: de_DE.UTF-8
Major mode: Lisp Interaction
Minor modes in effect:
bug#44666: 28.0.50; malloc-info: Emacs became not responsive, using hard disk all time
* Eli Zaretskii <[hidden email]> [2020-11-17 10:04]:
> > If there is nothing to be done with this bug, we can close.
> No, closing is premature. I've merged this bug with 3 other similar
> ones, and we are discussing this issue with glibc malloc experts.
If bug is merged, do I just reply on this email?
My emacs-uptime now is 19 hours, and I can see 4819 MB swapping
according to symon-mode
I have not get number of buffers, I tried to delete it and there is no
change. User processes are below. I have not finished this session and
so I am prematurely sending the file
emacs.strace-2020-11-18-14:42:59-Wednesday which may be accessed here
below on the link. I could not copy the file fully through eshell probably
because if I do copy through eshell the strace becomes longer and
longer and copy never finishes. So I have aborted the copy, file may
not be complete. It is also not complete for reason that session is
> Date: Thu, 19 Nov 2020 09:59:44 +0300
> From: Jean Louis <[hidden email]>
> Cc: [hidden email] >
> * Eli Zaretskii <[hidden email]> [2020-11-17 10:04]:
> > > If there is nothing to be done with this bug, we can close.
> > No, closing is premature. I've merged this bug with 3 other similar
> > ones, and we are discussing this issue with glibc malloc experts.
> If bug is merged, do I just reply on this email?
No, it's better to reply to bug#43389 (I've redirected the discussion
now), and please keep the other addressees on the CC list, as they are
not subscribed to the bug list, I believe.
> My emacs-uptime now is 19 hours, and I can see 4819 MB swapping
> according to symon-mode
> I have not get number of buffers, I tried to delete it and there is no
> change. User processes are below. I have not finished this session and
> so I am prematurely sending the file
> emacs.strace-2020-11-18-14:42:59-Wednesday which may be accessed here
> below on the link. I could not copy the file fully through eshell probably
> because if I do copy through eshell the strace becomes longer and
> longer and copy never finishes. So I have aborted the copy, file may
> not be complete. It is also not complete for reason that session is
> not finished.
> strace is here, 13M download, when unpacked it is more than 1.2 GB.
I've looked at that file, but couldn't see any smoking guns. It shows
that your brk goes up and up and up until it reaches more than 7GB.
Some of the requests come in groups, totaling about 5MB, not sure why
(these groups always follow a call to timerfd_settime, which seems to
hint that we are setting an atimer for something). However, without
time stamps for each syscall, it is hard to tell whether these series
of calls to 'brk' are indeed made one after the other, nor whether
they are indeed related to something we use atimers for, because it is
unknown how much time passed between these calls.
I think you should try using the malloc tracing tools pointed to here:
Correct, that is a different malloc implementation and may have
completely different behaviour for your given workload. That is
not to say that it isn't viable solution to try another allocator
that matches your workload. However, in this bug we're trying to
determine why the "default" configuration of emacs and glibc's
allocator causes memory usage to grow.
We want to run the glibc malloc algorithms because that is the
implementation under which we are observing the increased memory
pressure. The tracer I've suggested will get us an API trace
that we can use to determine if it is actually API calls that
are causing an increase in the memory usage or if it's an
algorithmic issue. It is not always obvious to see from the
API calls, but having the trace is better than not.
It will not help if you are able to interpret the PDF reports and you
do not see anything helpful. If you do interpret those PDF reports
please tell me as such could be useful to find possible causes or find
other issues in Emacs.
I am using dynamic modules like vterm and libpq, can that influence
memory or create memory leaks?
What is tst_post_reentrancy_raw, is that something that eats memory?
I am still running this session with jemalloc and I wish to see if
anything will happen that blocks the work similar how it blocks with
the normal run. This helps slightly in determination. As if run of
Emacs with jemalloc does not cause problems one time, maybe 2-5 times
or 10 times, that may be deduce problem to standard malloc and not
Then in the next session I will try again the tools as described and
To help me understand, do you think problem is in Emacs or in glibc
It says that most of memory was allocated by a subroutine of jemalloc. As I'm not familiar with how jemalloc works, I see no way for us to draw any significant conclusions from that.
> Does this add module isra.0 inside tells you anything?
AFAIU, it's some internal jemalloc midule.
> I am using dynamic modules like vterm and libpq, can that influence
> memory or create memory leaks?
I have no idea, but I don't think I see any of their functions in these reports.
> What is tst_post_reentrancy_raw, is that something that eats memory?
I don't know. It's something internal to jemalloc.
> I am still running this session with jemalloc and I wish to see if
> anything will happen that blocks the work similar how it blocks with
> the normal run. This helps slightly in determination. As if run of
> Emacs with jemalloc does not cause problems one time, maybe 2-5 times
> or 10 times, that may be deduce problem to standard malloc and not
The glibc malloc is the prime suspect anyway. I don't really believe Emacs had such a glaring memory leak. So trying different malloc implementations is from my POV waste of time at this stage.
> Then in the next session I will try again the tools as described and
> submit data.
> To help me understand, do you think problem is in Emacs or in glibc
I suspect the problem is in how we use glibc's malloc -- there are some usage patterns that cause glibc to be suboptimal in its memory usage, and I hope we will find ways to fine tune it to our needs.
But that is just a guess, and so I wish you'd use the tools pointed out by Carlos, because they are the most efficient way of collecting evidence that might allow us to make some progress here.
We have the attention of the best experts on the issue; let's use their attention and their time as best as we possibly can.
The session I was running with jemalloc memory leak logging is
Just the same thing happened. It started getting slower and slower.
In the IceWM window manager I have visual representation of memory
usage and that is how I get feeling, there is also tooltip telling me
that more and more memory is used. When it starts to swap like 3 GB
then I turn on symon-mode and in Emacs I see more and more swapping.
> On 11/19/20 10:16 PM, Jean Louis wrote:
> > * Eli Zaretskii <[hidden email]> [2020-11-19 17:38]:
> >> I think you should try using the malloc tracing tools pointed to here:
> >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43389#158 > >
> > When running for long time Emacs will crush at certain point of time
> > as my hard disk get full as /tmp is just about 2 gigabytes. I did not
> > understand Carlos how to change the location for files.
> The glibc malloc tracer functionality can be adjusted with environment
> MTRACE_CTL_VERBOSE=1 MTRACE_CTL_FILE=./ls.mtr LD_PRELOAD=./libmtrace.so ls
> mtrace: writing to ./ls.mtr.350802
> The appended PID helps keep the files distinct (and includes a sequence
> number in the event of conflict).
It is important to have both these pieces of information from the same
session at the same time near the point where you must kill Emacs, so
that we know how much memory is actually used by your session at that
point (as opposed to memory that is "free" in the heap, but was not
returned to the OS).
>> Date: Mon, 23 Nov 2020 13:59:47 +0300
>> From: Jean Louis <[hidden email]>
>> Cc: [hidden email], [hidden email], [hidden email],
>> [hidden email], [hidden email], [hidden email] >>
>> In the IceWM window manager I have visual representation of memory
>> usage and that is how I get feeling, there is also tooltip telling me
>> that more and more memory is used. When it starts to swap like 3 GB
>> then I turn on symon-mode and in Emacs I see more and more swapping.
> I think I described how to write an Emacs function that you could use
> to watch the vsize of the Emacs process and alert you to it being
> above some threshold.
>> The heap file is here 24M, maybe not needed for review:
>> https://gnu.support/files/tmp/2020-11-23/jeprof.23826.0.f.heap >>
>> Visualization is here 20K PDF file:
>> https://gnu.support/files/tmp/2020-11-23/jeprof.23826.0.f.heap.pdf >>
>> Do you see anything interesting inside that should tell about memory leaks?
> I'm not sure. I think I see that you have some timer that triggers a
> lot of memory allocations because it conses a lot of Lisp objects.
> Whether that is part of the problem or not is not clear.
> Next time when your session causes the system to swap, please type:
> M-: (garbage-collect) RET
> and post here the output of that (it should be a list of numbers
> whose meanings are explained in the doc string of garbage-collect).
> Also, I think I asked to tell how large are your buffers by evaluation
> the following (again, near the point where your session causes the
> system to page heavily):
> (let ((size 0))
> (dolist (buffer (buffer-list) size)
> (setq size (+ size (buffer-size buffer)))))
> It is important to have both these pieces of information from the same
> session at the same time near the point where you must kill Emacs, so
> that we know how much memory is actually used by your session at that
> point (as opposed to memory that is "free" in the heap, but was not
> returned to the OS).
For me it happends like really, really fast. Things work normally, and
then suddenly everythign freezes, and after first freeze, it takes for
every to see result of any keypress. For example video in Firefox gets
slow down to like a frame per minut or so; I can see that system is
alive, but it is impossible to type something like (garbage-collect) and
see the result; I would be sitting here for a day :-).
The only thing I can is switch to another console, and then back. By
that time Emacs process is restarted and everything is normal. I don't
use swap file at all, and I can't believe that Emacs is eating up 32 gig
or RAM either. However I can't type any command to see what it is
peeking at since everything is efefctively frozen. I have seen it at 800
meg on my machine at some time, but it is far away from 32 gig I have.
Maybe, I'm not sure. Since we introduced the pdumper, we use malloc
somewhat differently, and OTOH glibc removed some of the malloc hooks
we used to use in versions of Emacs before 26. In addition, glibc is
also being developed, and maybe some change there somehow triggered
As you see, there's more than one factor that could possibly be
> I didn't have any such problems before, but since maybe few weeks ago, I
> have also experienced heavy lockdowns of my entire OS. To the point
> where entire X11 got unresposnsive, when it happens I can't even switch
> to terminal to kill Emacs. What I do is Alt-Shift to another virtual
> linux console. I don't even need to log into the system in that console,
> I can then Alt-Shift 1 to go back to one I am logged into, and
> everything is normal. Emacs is every time restarted by systemd and
> everything is repsonsive and working as normal.
> This started sometime ago; and I have noticed that it happens when I was
> cleaning my disk and reading big directories in Dired (I have some with
> ~7k-10k files in them). I was using Helm to complete paths when I was
> shifting fiels and folders around. After maybe hour or so I would
> experience big slowdown. I don't have swap file on my system enabled at
> all, so I am not sure what was going, but I didn't have time to
> participate in this memory leak thing yet. I haven't experienced any
> problems since I recompiled Emacs last time, which was in 18th (last
> Wendesday). I have recompiled without Gtk this time, but I have no idea
> if it has anything to do with the issue, was just a wild shot to see if
> things are better.
If the problem is memory, I suggest to look at the system log to see
if there are any signs of that.