On 31/03/2025 15:23, Andrea Corallo wrote:
> I think the expected observation would be like:
>
> 1- you have your Emacs process X running, there the mem consumption is
> normal.
>
> 2- you observe a process Y (child of X) which is another Emacs, this one
> is the one doing the actual compilation and is supposed to be the one
> going overboard with memory allocation.
I do see that, however once compilation is done that process is stopped,
releasing that memory, but the main process keeps steadily increasing its
usage (along with cpu usage remaining).
> Profiling memory allocation in process Y should reveal who it's actually
> allocating.
I wasn't sure what "profiling memory allocation" meant, so after a quick
search I found 'heaptrack', which appears to do that? I've attached the
produced file from it after causing the leak and waiting for it to reach
1G of used memory.
 From what I can read from the summary, the leak comes from a "location"
it describes as "<unresolved function> in emacs-30.1", which produces
most of the memory leak which appears to be in hundreds of thousands of
allocations of 1.0K and around that.
It also shows a contribution by "libglib-2.0.so.0", which is also
hundreds of thousands of allocations, but only around 5M total, so
entirely irrelevant… There is also a leak of 75.4M from "xrealloc",
which I assume is the compilation.
Is that helpful? I could also try another utility if that'd be better.

   N