From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: memory leak Date: Fri, 28 Apr 2006 20:56:40 -0500 (CDT) Message-ID: <200604290156.k3T1uecx028681@jane.dms.auburn.edu> References: NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1146275868 1533 80.91.229.2 (29 Apr 2006 01:57:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 29 Apr 2006 01:57:48 +0000 (UTC) Cc: bob@rattlesnake.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 29 03:57:40 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FZeiJ-0004Se-L3 for ged-emacs-devel@m.gmane.org; Sat, 29 Apr 2006 03:57:39 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FZeiJ-0000Ym-6v for ged-emacs-devel@m.gmane.org; Fri, 28 Apr 2006 21:57:39 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FZei6-0000Yd-UD for emacs-devel@gnu.org; Fri, 28 Apr 2006 21:57:26 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FZei6-0000YR-2O for emacs-devel@gnu.org; Fri, 28 Apr 2006 21:57:26 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FZei5-0000YN-VA for emacs-devel@gnu.org; Fri, 28 Apr 2006 21:57:25 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FZelL-0004tY-V2 for emacs-devel@gnu.org; Fri, 28 Apr 2006 22:00:48 -0400 Original-Received: from jane.dms.auburn.edu (jane.dms.auburn.edu [131.204.53.201]) by manatee.dms.auburn.edu (8.13.6/8.13.6) with ESMTP id k3T1vOst022907; Fri, 28 Apr 2006 20:57:24 -0500 (CDT) Original-Received: from jane.dms.auburn.edu (localhost [127.0.0.1]) by jane.dms.auburn.edu (8.13.4+Sun/8.13.3) with ESMTP id k3T1ueux028684; Fri, 28 Apr 2006 20:56:40 -0500 (CDT) Original-Received: (from teirllm@localhost) by jane.dms.auburn.edu (8.13.4+Sun/8.13.3/Submit) id k3T1uecx028681; Fri, 28 Apr 2006 20:56:40 -0500 (CDT) X-Authentication-Warning: jane.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: bob@rattlesnake.com In-reply-to: (bob@rattlesnake.com) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:53574 Archived-At: Robert Chassell wrote: Can anyone else reproduce a memory leak in the current CVS GNU/Emacs? Not me. First of all, I guess that you checked that building Emacs did not overflow pure storage. Doing so will definitely produce the results you describe. You can check whether the variable pure-space-overflow is really non-nil or whether (garbage-collect) returns a non-nil value (it should). If that is not the problem, I definitely know a way to produce something that looks very much like a memory leak, although it is not. All you have to do is have a large number of large files open that require a lot of fontification, with global-font-lock-mode enabled. If you have ten or so files the size of lisp/Changelog open, then after you completely quit using Emacs, the memory consumed by the Emacs process can easily grow by more than 35 percent, or 8M or more, over a period spanning an hour or more on a fast machine. Except for the apparent "memory leak" there also is an apparent rogue CPU usage. There is no real memory leak however. After an hour or more, when all buffers are completely fontified, both CPU usage and "memory leak" completely stop. These instances of GNU Emacs appear to consume RAM at a rate of 124 kb/min. I got at least that in my experiments with opening many large files. But the memory consumption eventually stops, maybe after many hours on a slow machine. I can not reproduce anything that even mimics a memory leak without _both_ global-font-lock-mode being enabled _and_ a large number of large files requiring heavy fontification being open. Sincerely, Luc.