GNU bug report logs - #49656
Abnormal Emacs memory usage (bug#43389)

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Madhu <enometh <at> meer.net>
Cc: 49656 <at> debbugs.gnu.org
Subject: Re: bug#49656: more data on #43389
Date: Tue, 20 Jul 2021 14:43:46 +0300

> Date: Tue, 20 Jul 2021 12:43:31 +0530 (IST)
> From: Madhu <enometh <at> meer.net>
> 
> This is the emacs memory bloat issue. I thought I had unarchived the
> bug earlier but it seems to be closed up again. Should I open a new
> bug? Its already got a 1000 posts on the bugzilla page

I'm not yet sure this is a bug, FWIW.

> Over the past few months, I've experienced the memory problem a few
> times.  I wanted to share the malloc info data I collected on 3
> instance and am attaching a tarball with 3 directories named 4 5 6
> which include malloc-info, memory-usage, and memory-report data from
> emacs exhibiting the behaviour - after all buffers are killed and
> after an M-x gc.
> 
> Directories 4 and 6 show the common pattern where memory is used
> unknown to GC. data in directory 5 probably another issue where there
> are a lot of dead strings.

I've looked at the data, thanks.  But the most important information
is missing from the data you presented.  The case where you have 570MB
in strings could be interesting, but without knowing what you did in
that session, it is impossible to say whether there's an issue there.
It could be explained by the live Lisp data you produced in that
session.

So what we need is the following, for each case separately:

  . the size of the memory footprint of the Emacs session
  . how long was the Emacs session running since it started
  . what were the main activities in that session
  . do you have some customizations related to GC, and if you do, what
    are they
  . what Emacs version is that, and what are its configuration
    parameters and features compiled into it

In general, that old bug is closed, because after making a single
change that did cause memory bloat in some usage patterns, we
concluded that the rest were user problems caused by messing with GC
thresholds.  The glibc developers looked at the data we collected and
found nothing that could be interpreted as a bug in glibc.

TIA

Previous Next

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