From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#43389: 28.0.50; Emacs memory leaks Date: Wed, 16 Sep 2020 17:52:48 +0300 Message-ID: <83pn6l7ozj.fsf@gnu.org> References: <87r1r5428d.fsf@web.de> <87mu1sry72.fsf@mail.linkov.net> <875z8fc224.fsf@web.de> <20200915175418.GV20869@maokai> <838sda98jm.fsf@gnu.org> <20200915211209.GW20869@maokai> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25532"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 43389@debbugs.gnu.org To: Russell Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Sep 16 16:53:48 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kIYod-0006Xo-SJ for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 16 Sep 2020 16:53:47 +0200 Original-Received: from localhost ([::1]:46682 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kIYoc-00040z-VB for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 16 Sep 2020 10:53:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51502) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kIYnu-0003aj-Of for bug-gnu-emacs@gnu.org; Wed, 16 Sep 2020 10:53:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52356) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kIYnu-0000Xq-EO for bug-gnu-emacs@gnu.org; Wed, 16 Sep 2020 10:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kIYnu-0000ze-D9 for bug-gnu-emacs@gnu.org; Wed, 16 Sep 2020 10:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Sep 2020 14:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43389 X-GNU-PR-Package: emacs Original-Received: via spool by 43389-submit@debbugs.gnu.org id=B43389.16002679673793 (code B ref 43389); Wed, 16 Sep 2020 14:53:02 +0000 Original-Received: (at 43389) by debbugs.gnu.org; 16 Sep 2020 14:52:47 +0000 Original-Received: from localhost ([127.0.0.1]:35669 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kIYne-0000z7-OR for submit@debbugs.gnu.org; Wed, 16 Sep 2020 10:52:46 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:44534) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kIYnd-0000yq-Fs for 43389@debbugs.gnu.org; Wed, 16 Sep 2020 10:52:45 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41935) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kIYnX-0000Vk-Rn; Wed, 16 Sep 2020 10:52:39 -0400 Original-Received: from [176.228.60.248] (port=3115 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kIYnX-0004rS-9n; Wed, 16 Sep 2020 10:52:39 -0400 In-Reply-To: <20200915211209.GW20869@maokai> (message from Russell Adams on Tue, 15 Sep 2020 23:12:09 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:188169 Archived-At: > Date: Tue, 15 Sep 2020 23:12:09 +0200 > From: Russell Adams > > > Can you use some utility that produces a memory map of an application, > > and see how much of those 5GB are actually free for allocation by > > Emacs? > > Any suggestions? Your Internet search is as good as mine. This page offers some possibilities: https://stackoverflow.com/questions/36523584/how-to-see-memory-layout-of-my-program-in-c-during-run-time > > Also, do you see any libraries used by Emacs that have high > > memory usage? > > Emacs is the top memory usage on my laptop, firefox is second at > 2GB. The rest are <1G. No, I meant the shared libraries that Emacs loads. Maybe one of them has a leak, not Emacs's own code. > > 28% and 33% of what amount? > > 16GB > > > If your RSS is 5GB after 4 days of uptime, and the memory footprint > > grows at a constant rate, it would mean more than 1GB per day. But > > I'm guessing that 33% - 28% = 5% of your total memory is much less > > than 1GB. > > No, 33% is ~5GB. ;] > > > In which case the memory footprint must sometimes jump by > > very large amounts, not grow slowly and monotonically each day. > > Right? So which events cause those sudden increases in RSS? > > I can't say. Well, actually the above seems to indicate that your memory footprint grows by about 1GB each day: 5% of 16GB is 0.8GB. So maybe my guess is wrong, and the memory does increase roughly linearly with time. Hmm... We had a discussion several times regarding the possible effects of the fact that glibc doesn't return malloc'ed memory to the system. I don't think we reached any firm conclusions about that, but it could be that some usage patterns cause memory fragmentation, whereby small chunks of free'd memory gets "trapped" between regions of used memory, and cannot be reallocated. We used to use some specialized malloc features to prevent this, but AFAIU they are no longer supported on modern GNU/Linux systems. Not sure whether this is relevant to what you see. Anyway, I think the way forward is to try to understand which code "owns" the bulk of the 5GB memory. Then maybe we will have some ideas. Thanks.