GNU bug report logs -
#43389
28.0.50; Emacs memory leaks
Previous Next
Full log
View this message in rfc822 format
> Date: Thu, 26 Nov 2020 12:09:32 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: Carlos O'Donell <carlos <at> redhat.com>, trevor <at> trevorbentley.com,
> fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org, dj <at> redhat.com,
> michael_heerdegen <at> web.de
>
> ((uptime "2 days, 18 hours, 35 minutes, 19 seconds") (pid 13339) (garbage ((conses 16 4511014 617524) (symbols 48 86926 23) (strings 32 576134 114546) (string-bytes 1 25198549) (vectors 16 245670) (vector-slots 8 4636183 1560354) (floats 8 1859 18842) (intervals 56 655325 24178) (buffers 992 900))) (buffers-size 200898858) (vsize (vsize 5144252)))
>
> But what happened after 36 minutes of waiting is that Emacs became
> responsive. So I am still running this session and I hope to get
> mtrace after the session has finished.
>
> Before I was not patient longer than maybe 3-5 minutes and I have
> aborted Emacs. But now I can see it stabilized after hard work with
> memory or whatever it was doing. Swap is 1809 MB and vsize just same
> as above.
It's still 5GB, which is a fairly large footprint, certainly for a
2-day session.
> Observation on "what I was doing when vsize started growing" is
> simple, I was just editing email, nothing drastic. I did not do
> anything special.
Can you describe in more detail how you edit email? Which email
package(s) do you do, and what would composing email generally
involve?
Also, are there any background activities that routinely run in your
Emacs sessions?
> If you say I should finish session now and send the mtrace, I can do
> it.
That's for Carlos to say.
Thanks for the info.
This bug report was last modified 4 years and 58 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.