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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Carlos O'Donell <carlos <at> redhat.com>
Cc: fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org, dj <at> redhat.com
Subject: Re: bug#43389: 28.0.50; Emacs memory leaks
Date: Tue, 17 Nov 2020 19:13:06 +0200

> Cc: dj <at> redhat.com, 43389 <at> debbugs.gnu.org
> From: Carlos O'Donell <carlos <at> redhat.com>
> Date: Tue, 17 Nov 2020 11:32:23 -0500
> 
> > "Small value" being something like 2?
> 
> The current code creates 8 arenas per core on a 64-bit system.
> 
> You could set it to 1 arena per core to force more threads into the 
> arenas and push them to reuse more chunks.
> 
> export MALLOC_ARENA_MAX=$(nproc)

Isn't that too many?  Emacs is a single-threaded program, with a small
number of GTK threads that aren't supposed to allocate a lot of
memory.  Sounds like 2 should be enough, no?

> > Any other suggestions or thoughts?
> 
> Yes, we have malloc trace utilities for capturing and simulating traces
> from applications:
> 
> https://pagure.io/glibc-malloc-trace-utils
> 
> If you can capture the application allocations with the tracer then we
> should be able to reproduce it locally and observe the problem.

You mean, trace all the memory allocations in Emacs with the tracer?
That would produce huge amounts of data, as Emacs calls malloc at an
insane frequency.  Or maybe I don't understand what kind of tracing
procedure you had in mind (I never used these tools, and didn't know
they existed until you pointed to them).

Thanks.

Previous Next

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