From xemacs-m  Sun Mar  2 16:52:28 1997
Received: from cs.uchicago.edu (alexandria.cs.uchicago.edu [128.135.11.87])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id QAA01049
	for <xemacs-beta@xemacs.org>; Sun, 2 Mar 1997 16:52:28 -0600 (CST)
Received: from jordan.cs.uchicago.edu (jordan [128.135.164.50]) by cs.uchicago.edu (8.8.5/8.7.3) with ESMTP id QAA15065 for <xemacs-beta@xemacs.org>; Sun, 2 Mar 1997 16:52:29 -0600 (CST)
Received: from jordan (localhost [127.0.0.1]) by jordan.cs.uchicago.edu (8.8.5/8.7.3) with ESMTP id QAA24784 for <xemacs-beta@xemacs.org>; Sun, 2 Mar 1997 16:52:28 -0600 (CST)
X-Face: `X="Sg7A[PL3/_8;>>ggjOy&\KtWiH7.wQ>Y"hQ2fxSG9RkPTCT}&^()5[Gp(-DaTf:t`MSBt@Li_C9U@y#i/c?i$uLQ8[';I$mMAm_rZta>l`STW_aA5`iD[!80p#_qmN4#tMu[Pu7wkIi)5*4YXAhg)9R2-BAWPbVOzgE$Ib4QuZn0YaE~'C/7h^CTuPybz$u
Mail-Copies-To: never
To: xemacs-beta@xemacs.org
Subject: Re: memory leak?
References: <xcdlo86yn2k.fsf@jordan.cs.uchicago.edu> <m2rahxvrfu.fsf@altair.xemacs.org>
Mime-Version: 1.0 (generated by tm-edit 7.101)
Content-Type: text/plain; charset=US-ASCII
From: Soren Dayton <csdayton@cs.uchicago.edu>
Date: 02 Mar 1997 16:52:27 -0600
In-Reply-To: Steven L Baur's message of 02 Mar 1997 14:51:01 -0800
Message-ID: <xcdbu91zz2s.fsf@jordan.cs.uchicago.edu>
Lines: 32
X-Mailer: Gnus v5.4.12/XEmacs 20.0
Sender: csdayton@cs.uchicago.edu

Steven L Baur <steve@miranova.com> writes:

> Soren Dayton writes:
> 
> > I just performed an experiment.   I decided to read
> > clari.living.comics.doonesbury 10 times to see what happened to the
> > memory that my XEmacs was taking up.
>  ...
> > This stinks of a memory leak to me.  Is this a known problem?
> 
> It could be.  Gnus has been known to exercise bad code in XEmacs.
> What kind of group is clari.living.comics.doonesbury?

the doonesbury comic.  gifs.

>                                                        There aren't
> any messages in it on my nntp server.  The first thing I'd suspect
> would be image display.  The new tm code to display images decodes
> them multiple times.

Yup.

> Do an explicit (garbage-collect) in the *scratch* buffer to see memory
> usage stats.  Maybe it will tell you something.

tells me a lot.  None of it means much to me though:

image-instances-used 62 image-instance-storage 3968

is about the only thing that occurs to me that might be relevant.

Soren

