GNU bug report logs - #43389
28.0.50; Emacs memory leaks

Previous Next

Full log

Message #248 received at 43389 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org, dj <at> redhat.com,
 michael_heerdegen <at> web.de, trevor <at> trevorbentley.com, carlos <at> redhat.com
Subject: bug#43389: 28.0.50; Emacs memory leaks
 using hard disk all time
Date: Thu, 19 Nov 2020 16:37:39 +0200

> Date: Thu, 19 Nov 2020 09:59:44 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: 44666 <at> debbugs.gnu.org
> 
> * Eli Zaretskii <eliz <at> gnu.org> [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.
> https://gnu.support/files/tmp/emacs.strace-2020-11-18-14:42:59-Wednesday.lz

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:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43389#158

Also, next time your vsize is several GBytes, please see how much do
your buffers take, by evaluating this form:

 (let ((size 0))
   (dolist (buffer (buffer-list) size)
     (setq size (+ size (buffer-size buffer)))))

Previous Next

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