>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.

you've just got to find the correct key.   ctrl-alt-f7 works for me (using
pcvt).


>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.

that's interesting, but there is not enough info to know what is going
on yet.    you say the 320K returns to the free list when the X server
exits?   in that case, it would be useful to look at the output of 
ddb's "show map/f" on the X server's map from "exited" to "execed" to 
"exited" and see what mappings changed.    i'd prob. comment out the 
call to _vm_object_print() in _vm_map_print() to reduce the noise in
ddb's output.

chuck