Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!brutus.cs.uiuc.edu!lll-winken!decwrl!pandora.pa.dec.com!joel
From: joel@pandora.pa.dec.com (Joel McCormack)
Newsgroups: comp.unix.ultrix
Subject: Memory ``leaks'' in DEC servers
Message-ID: <2973@bacchus.dec.com>
Date: 7 Mar 90 01:15:45 GMT
Sender: news@decwrl.dec.com
Reply-To: joel@decwrl.dec.com
Organization: DEC Western Research Laboratory
Lines: 56

I have received several replies about how to reproduce ``leaks'' in the
server, for which I am quite grateful.  Using some of the examples
provided, I can sure get some surprisingly large amounts of memory used,
especially using PostScript.  For example, I've run my server up to
about 10.5 megabytes.  Yuck.

In addition, there is evidently a real leak in PostScript that is known
about.  Unfortunately for you all, I haven't found any other, unknown
memory leak.  Allow me to clarify a few points:

(1) There is no way to give memory back to the kernel once it is
allocated.  So killing off all of your applications will not reduce the
total amount of memory consumed by the server.  It should reduce the
amount of memory needed to be resident.

(2) Running some new application may require more memory from the server
than it already has allocated, and you may find this number to be
unacceptably large.  This is usually caused by fragmentation.  While I
would like to improve general memory usage, this is a separate problem
from a memory leak.  Note that no X server that I know of uses a
compacting garbage collector, so fragmentation is bound to be a problem
to some extent in all servers.

(3) A memory leak means that you can cycle through some series of
actions, and the server will grow infinitely.  If you cannot give me
such an example, you are not demonstrating a leak.

(4) Using PostScript evidently uses up a lot of memory.  The people who
implemented the PostScript extension are looking into this.  In
addition, there is an actual leak in PostScript code in the UWS 2.2
server: Adobe thought we'd free the memory, we thought they would.

(5) Backing store uses up A LOT of memory.  Backing store allocates a
pixmap as large as your window, at 8 bits per pixel.  It is quite easy
to use up several megabytes this way.  In general, don't use backing
store unless it is quite expensive to repaint a window.

(6) Some incorrect clients can allocate resources in the server and not
free them.  The server can't reclaim any of the associated storage for
use by other clients until the offending client terminates.  The
specific program mentioned was the awm window manager.  This is
particularly bad, because you don't normally terminate a window manager.

So keep trying for a leak.  Also, if anyone has noticed something that
doesn't use PostScript or backing store, but uses a lot more memory than
it used to under earlier servers, I'm interested.  The server really
shouldn't be using any more storage for boring old X stuff than it used to.

I also mentioned to the appropriate people about how some of you would
like new servers with bug fixes made available on gatekeeper.  While I
think this is a fine idea given the way the product release cycle groans
along, they get all paranoid about bugs coming in on lots of different
versions of the server, or bugs coming in for other software that is
really caused by new buggy servers, etc.

- Joel McCormack (decwrl!joel, joel@decwrl.dec.com)