From xemacs-m  Fri Sep  5 01:04:15 1997
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by xemacs.org (8.8.5/8.8.5) with SMTP id BAA10272
	for <xemacs-beta@xemacs.org>; Fri, 5 Sep 1997 01:04:14 -0500 (CDT)
Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA05779; Thu, 4 Sep 1997 12:55:34 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id MAA28192; Thu, 4 Sep 1997 12:55:01 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id MAA20405; Thu, 4 Sep 1997 12:54:50 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id MAA21427; Thu, 4 Sep 1997 12:54:48 -0700
Date: Thu, 4 Sep 1997 12:54:48 -0700
Message-Id: <199709041954.MAA21427@xemacs.eng.sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Mark Borges <mdb@cdc.noaa.gov>
Cc: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: Re: [PATCH]  Re: Kyiv package failure under sparc-sun-solaris2.5.1
In-Reply-To: <vkk9gxja7c.fsf@cdc.noaa.gov>
References: <ocrbu2al4j1.fsf@ml.com>
	<m2bu2a5cpc.fsf@altair.xemacs.org>
	<ocr7mcykqza.fsf@ml.com>
	<m24t81vqut.fsf@altair.xemacs.org>
	<ocrg1rlgnmm.fsf@ml.com>
	<QQdfoh29187.199709041546@crystal.WonderWorks.COM>
	<vkk9gxja7c.fsf@cdc.noaa.gov>
X-Mailer: VM 6.33 under 20.3 "Vienna" XEmacs  Lucid (beta14)
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>

>>>>> "mb" == Mark Borges <mdb@cdc.noaa.gov> writes:

mb> And users here have noted that leaving XEmacs running for more
mb> than a day or so leads to very large memory consumption (one user
mb> was up to 72Mb private (according to a /usr/proc/bin/pmap
mb> accounting on Solaris-2.5) after running XEmacs-19.15 for five
mb> days). I'm under the impression that this is due to extensive
mb> font-locking, Gnus reading, VM reading, etc. and not a real memory
mb> leak, since the code has been run under something like Purify in
mb> the past, right?

I've purified the code for memory access violations, but not done any
leak detection work.  It's hard to do when old memory gets
garbage-collected, instead of free'd.  The garbage collector can find
memory that isn't being pointed to by anything.  In fact, that's its
job.  Purify and friends don't understand that.  So there may indeed
be lots of leaks in XEmacs, and a fertile ground for exploration.  It
will take more than just running Purify, though (like maybe calling
Purify's leak detector only immediately after the garbage collector
has done its dirty work).

Martin

