Subject: further vm adventures
To: Chuck Cranor <chuck@maria.wustl.edu>
From: None <jiho@postal.c-zone.net>
List: tech-kern
Date: 04/25/1998 14:00:53
I have finally isolated the fact that a (sometimes) large memory leak -- which
I've experienced for years -- ONLY occurs while running X clients.  It does NOT
occur in character-mode situations.

Here's a sample scenario.

Suppose I come up on the X desktop running a file manager, open an xterm, and
run 'systat vmstat' (Chuck's heart sinks).  After running an image-intesive
client a few times with the same data, things settle out into the following
consistent pattern:

              exited  execed  exited  execed  exited
              ------  ------  ------  ------  ------
      wired:   2332K   2356K   2332K   2356K   2332K
     active:   7972K   9604K   8292K   9924K   8616K
   inactive:   1376K    988K   1376K    988K   1376K
       free:  11456K  10188K  11136K   9868K  10812K

The X server gains 8K in its RSS across each interation.  No other programs
undergo any change.  The net result is that about 320K (give or take a 4K page)
is being lost from the free list to the active list on each iteration.  This
amount will vary depending on the data fed the client, but it will become
consistent for any given set of data.  I call this a leak because the client
has exited, and the memory at issue cannot be found associated with any other
program.

I am unable to use ddb in this situation, because although I can switch VTs to
enter ddb, once leaving ddb there is no way to get back to the X desktop.

Anyone know -- or have any guesses -- what this might be about?

The only thing I see that distinguishes an X session from the command line is
that the X server and xterm are both suid.  But I'm logged in as root, so even
if that might (somehow) have a bearing, I fail to see how it could be relevant
here.

Of course, clients and server communicate over loopback sockets, but I don't
know enough about the networking code to analyze that.  (Imagine for a moment
that because it's a loopback, the network code doesn't know to deallocate the
destination for the transaction....forgive me, but I'm desperate.)


--Jim Howard  <jiho@mail.c-zone.net>


----------------------------------
E-Mail: jiho@mail.c-zone.net
Date: 25-Apr-98
Time: 14:00:53

This message was sent by XFMail
----------------------------------