From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: handa@gnu.org (K. Handa) Newsgroups: gmane.emacs.bugs Subject: bug#21556: 25.0.50; Memory leak in emacs -Q with lucid (font) Date: Sun, 27 Sep 2015 16:56:47 +0900 Message-ID: <87zj082t34.fsf@gnu.org> References: <87d1x7e53b.fsf@secretsauce.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1443340706 18943 80.91.229.3 (27 Sep 2015 07:58:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Sep 2015 07:58:26 +0000 (UTC) Cc: dmantipov@yandex.ru, 21556@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Sep 27 09:58:12 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zg6qZ-0001q5-Kp for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Sep 2015 09:58:11 +0200 Original-Received: from localhost ([::1]:56475 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zg6qZ-0002Qy-C9 for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Sep 2015 03:58:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51736) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zg6qV-0002Qh-V5 for bug-gnu-emacs@gnu.org; Sun, 27 Sep 2015 03:58:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zg6qQ-0008AU-SY for bug-gnu-emacs@gnu.org; Sun, 27 Sep 2015 03:58:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:56513) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zg6qQ-0008AQ-Pl for bug-gnu-emacs@gnu.org; Sun, 27 Sep 2015 03:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zg6qQ-0005XL-HB for bug-gnu-emacs@gnu.org; Sun, 27 Sep 2015 03:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: handa@gnu.org (K. Handa) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Sep 2015 07:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21556 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21556-submit@debbugs.gnu.org id=B21556.144334062421217 (code B ref 21556); Sun, 27 Sep 2015 07:58:02 +0000 Original-Received: (at 21556) by debbugs.gnu.org; 27 Sep 2015 07:57:04 +0000 Original-Received: from localhost ([127.0.0.1]:45484 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zg6pT-0005W9-1W for submit@debbugs.gnu.org; Sun, 27 Sep 2015 03:57:03 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41571) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zg6pQ-0005Vj-Ax for 21556@debbugs.gnu.org; Sun, 27 Sep 2015 03:57:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zg6pL-0007v7-05 for 21556@debbugs.gnu.org; Sun, 27 Sep 2015 03:56:59 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53568) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zg6pK-0007v3-TE; Sun, 27 Sep 2015 03:56:54 -0400 Original-Received: from fl1-133-203-86-7.iba.mesh.ad.jp ([133.203.86.7]:58059 helo=shatin) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Zg6pJ-0005p5-Pb; Sun, 27 Sep 2015 03:56:54 -0400 Original-Received: from handa by shatin with local (Exim 4.82) (envelope-from ) id 1Zg6pD-0002LF-QL; Sun, 27 Sep 2015 16:56:47 +0900 In-Reply-To: <83y4ftfbjw.fsf@gnu.org> (message from Eli Zaretskii on Sat, 26 Sep 2015 18:24:51 +0300) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:106958 Archived-At: In article <83y4ftfbjw.fsf@gnu.org>, Eli Zaretskii writes: > > > I guess I still don't know if the fonts are supposed to be marked or > > > not. They appear to never be marked. Do you know where that is supposed > > > to happen? > > > > > > Furthermore, the compaction code is incomplete, at least for xft. Xft > > > refence-counts the fonts, so you must close all fonts you have opened. > > > Emacs stores the fonts that have been opened in the cache, so if it ever > > > drops any fonts from the cache, it must tell xft to close, or else > > > things leak, as we're seeing. I haven't tried to do this yet, but I > > > suspect that the fonts should be marked, otherwise we'd be closing the > > > font that we have just opened. As the font compaction code (and some other work related to clearing font cache) is done by Dmitry, I included him in CC:. > > Originally, font caches were not compacted at all until that > > discussion in Oct 2013; they are still not compacted now on w32. To > > figure out how to compact those caches correctly, I think we need to > > start with the basics, and understand well the "life cycle" of a font > > in Emacs, including its font-cache entries: when and how a font is > > opened and registered in the cache, when and how (and whether) it is > > closed and removed from the cache, etc. This stuff is notoriously > > under-documented in Emacs, and we no longer have active maintainers on > > board who are familiar with it. > > > > So I'm afraid we are on our own wrt these issues. (I'm CC'ing > > Handa-san, who wrote most of the font-related code, in the hope that > > he could chime in at some point and help us.) I feel very guilty for those under-documented codes. When I wrote the original code long ago, font listing and opening was very slow on GNU/Linux system. So I tried to cache the result of listing as far as possible, and also tried to reuse the once opened font object as far as possible. The latter means that even if a font object once created becomes unnecessary (perhaps because a frame is deleted), it is not freed, because, once a user displayed a specific character, it is displayed again with a very high possibility. So, when a font is closed? It is closed by an explicit call of clear-font-fache. As far as I remember (though vaguely), that was my original intention. --- K. Handa handa@gnu.org