GNU bug report logs - #75672
31.0.50; scratch/igc memory usage/collection issues

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alexis Purslane <alexispurslane <at> pm.me>
Cc: 75672 <at> debbugs.gnu.org
Subject: bug#75672: 31.0.50; scratch/igc memory usage/collection issues
Date: Thu, 23 Jan 2025 09:26:23 +0200

> Date: Thu, 23 Jan 2025 01:46:51 +0000
> From: Alexis Purslane <alexispurslane <at> pm.me>
> Cc: 75672 <at> debbugs.gnu.org
> 
> An Emacs session got up to 1GB again (even after an M-x malloc-trim,
> which shaved like 100MB off!) so I set about trying to figure out how to
> get a GDB attached to it to dump its stderr so I could get the output of
> M-x malloc-info, but like ten minutes into that (GDB was missing some
> plugin so I couldn't run the code inside it necessary to open the file
> and redirect the output)

To avoid the need to use such complicated tricks, you could start
Emacs with stderr redirected to a file to begin with.

> suddenly it just.. freed all that memory and went down to 140MB of
> resident memory.

That's typical of glibc, and also for situations where some relatively
small chunk of used memory prevents releasing a large chunk of free
memory.  So I still don't see any signs of significant leaks here,
maybe just something related to how the MPS-managed memory is laid out
in the address space (do we even have any ways of controlling or
changing that?).

> But it /was/ resident memory, not virtual memory, that it was using,
> since it's still using 2GB of virtual memory.

You mean, Emacs now reserves 2GB, but has only 140MB committed?

Previous Next

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