GNU bug report logs - #45200
Wishlist: There should be a `malloc-trim' function

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Konstantin Kharlamov <hi-angel <at> yandex.ru>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 45200 <at> debbugs.gnu.org
Subject: bug#45200: Memory leaks: (garbage-collect) fails to reclaim memory
Date: Sun, 24 Jan 2021 16:20:22 -0500

> Sure, they have my report on the problem. In my text I was just trying to
> convince Stefan that this is not correct behaviour, whereas he was
> implying otherwise.

I'm not saying it's necessarily correct behavior.
What I'm saying is that the expectation that the temporary use of 200MB
should not affect the memory use later is unrealistic.

And also that if you (setq gc-cons-threshold most-positive-fixnum)
then you're simply asking for trouble unless you *really* know what
you're doing (in which case you'd understand that the above expectation
is unrealistic).

> Glibc could for example use statistics of previous allocation patterns
> to see if it's needed to release memory and how much, but this is not
> what happens. And I am not the only dissatisfied user. Ruby for
> example too¹. Also, many people experience strange memory usage grow
> with Qutebrowser that nobody knows where it's coming from; and after
> today's research I suspect Glibc is the culprit (I don't have yet
> enough evidence because my Qutebrowser instance doesn't have much
> uptime ATM, but attaching to it with gdb and calling `malloc_trim`
> inside it already freed ≈40M of memory to me today). Glib also seems
> affected².

Memory management is hard, and lots and lots of things can go wrong.
Maybe you're right and they're all due to some underlying problem
in glibc.  I suspect that instead the only thing in common is that
they're all problems with the memory management.


        Stefan

Previous Next

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