From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.bugs Subject: bug#38345: 27.0.50; Permanent increase in memory consumption after opening images (or pdfs) Date: Sun, 24 Nov 2019 00:04:17 +0800 Message-ID: <87h82u1svy.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> References: <87sgme1ww7.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> <83zhgmtznv.fsf@gnu.org> <87k17q1v0i.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> <83wobqtx4q.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="238777"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38345@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Nov 23 17:09:58 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iYXyw-000zxv-5S for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Nov 2019 17:09:58 +0100 Original-Received: from localhost ([::1]:59644 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iYXyu-0001Rf-Tv for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Nov 2019 11:09:56 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57162) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iYXw7-0000de-Pr for bug-gnu-emacs@gnu.org; Sat, 23 Nov 2019 11:07:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iYXw6-0004Th-Is for bug-gnu-emacs@gnu.org; Sat, 23 Nov 2019 11:07:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48822) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iYXw6-0004Ta-G1 for bug-gnu-emacs@gnu.org; Sat, 23 Nov 2019 11:07:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iYXw6-0005bH-8E for bug-gnu-emacs@gnu.org; Sat, 23 Nov 2019 11:07:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 Nov 2019 16:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38345 X-GNU-PR-Package: emacs Original-Received: via spool by 38345-submit@debbugs.gnu.org id=B38345.157452517421475 (code B ref 38345); Sat, 23 Nov 2019 16:07:02 +0000 Original-Received: (at 38345) by debbugs.gnu.org; 23 Nov 2019 16:06:14 +0000 Original-Received: from localhost ([127.0.0.1]:57643 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iYXvI-0005aG-0l for submit@debbugs.gnu.org; Sat, 23 Nov 2019 11:06:14 -0500 Original-Received: from mail-pf1-f194.google.com ([209.85.210.194]:43403) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iYXvE-0005a1-Bm for 38345@debbugs.gnu.org; Sat, 23 Nov 2019 11:06:09 -0500 Original-Received: by mail-pf1-f194.google.com with SMTP id 3so5139575pfb.10 for <38345@debbugs.gnu.org>; Sat, 23 Nov 2019 08:06:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=nY48vLzZH92YbGSN3CByfofDcsim8GzYw7rDj62Fco0=; b=Nvs4bChGcQEqoroFJLu2sVJH4qKVwY3MUsSONrVJ1JCTX/AxJS66cdN1nawLHlL3tL CD/854Fl7k7fpXb8wTEG0nZ5EU5DegkF5sH588ry5GNmzy6vkV9XohLXf6vWt3UYTmIp sE00RddTyteBWVjHoQH3JhFlMEl7/FW+08fsO7LDfdxa5G7w4pkwZFMkFqo4ikLl9h2k UjOYSV6700VukGlEAPPvg7zDwl3IqbBo9MJDfauK/SXdxqllJpxGRhCU2DMMs+7NY+vF ei16BsgfT549riXFbyh1xTfTuQnuN8pKjqMBeSh3FWM1kh8rAAJRd8C4RamegjF51bLM ML3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=nY48vLzZH92YbGSN3CByfofDcsim8GzYw7rDj62Fco0=; b=Q/O2w9IiWYBk6SuFWKCLKDeQ1jflOrcX/hNqv+lMa+XpgCrySR0MwV6i5r7C16vv5f hvKddfXmVd4AzeKcruumsNgK/lv7tuozcvaFhQv+ItEWMEc0R14SnN3ibJobortRgU1I mVotVYo+eI6Zy9oFPoXkmZD8rUw0P5LpZrEyR201qwEKJ8CQj4ju2BtFMGJHJWLr9d0N LKRScA/zpuN4GUGuULuXFYlD6seigUcKVzmDpP30AP3iU7CDTARcYwxgeyA3ghxgBJDw fLSO4pwvaSGXPL4AzpzyEwenJooCAFoAiR0URgGI4D61xPc3BUtT909Fb24YWOy1EDQq sV0A== X-Gm-Message-State: APjAAAVAQc2w3so+coxVXJFopl4gMbpK7A+zUXQWE0e4jyMJ/QswSAFr BzreS1E+j4mL6g6QpcvOV/Gma2PO3sg= X-Google-Smtp-Source: APXvYqxot3QRRZPP9GD3aF4VYeY7q5HvO1ez7yjCx5pS+MeyRNAcGMUsnrtP0bsOV5p1lO6ZiR90SA== X-Received: by 2002:a63:c0a:: with SMTP id b10mr22930994pgl.168.1574525161856; Sat, 23 Nov 2019 08:06:01 -0800 (PST) Original-Received: from localhost ([104.250.131.79]) by smtp.gmail.com with ESMTPSA id r28sm2306877pgk.75.2019.11.23.08.06.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 Nov 2019 08:06:01 -0800 (PST) In-Reply-To: <83wobqtx4q.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:172318 Archived-At: > memory allocated via malloc AFAIK gets grafted into the program's > address space, and when it is freed, it is left in the program's > address space, free to be used by that program for any further > allocation -- but is not returned to the system. So if you look at > the program's address space, you will think it only ever grows, > especially if you allocate a lot of memory before releasing the first > allocation. Hmm. Following an article by Dima Kogan [1], it appears to me that free() should de-allocate memory in the program's address space (or at least memory drop should be visible in the plot I got, since I used the same memory debugging tools) Best, Ihor [1] http://notes.secretsauce.net/notes/2015/10/05_memory-leak-debugging-tools.html Eli Zaretskii writes: >> From: Ihor Radchenko >> Cc: 38345@debbugs.gnu.org >> Date: Sat, 23 Nov 2019 23:18:21 +0800 >> >> What you say about Emacs not returning memory sounds like very very >> strange behaviour unless I misunderstand something. Does it mean that if >> I have emacs running as daemon and open a few hundreds of heavy pdfs >> during, say, a week, it will keep all the memory allocated for those pdfs >> (which is several Gb, at least)? If so, I don't think that Emacs should >> do it. > > It depends on how the memory is allocated. Memory allocated for > buffers gets returned to the OS when those buffers are killed. But > memory allocated via malloc AFAIK gets grafted into the program's > address space, and when it is freed, it is left in the program's > address space, free to be used by that program for any further > allocation -- but is not returned to the system. So if you look at > the program's address space, you will think it only ever grows, > especially if you allocate a lot of memory before releasing the first > allocation. > > At least that's what I think happens on modern platforms.