>I'll have to hassle with it to get useful stuff there, but I can tell you the
>only thing that changes is the unrelated allocation on top.  Under it we get
>these mis-matched entries we're talking about, and they don't change once they
>appear.  When they appear after the exec, they are already 1-page entries with
>40-page objects.  After the exit they haven't changed.

you might try ktrace'ing the X server during the loop (only) and extract
the mmap/munmap calls from the kdump output.   that way you could see 
if it is doing a partial deallocation.


>Or sbrk cycles.  Sbrk with negative change works just like munmap.  

right, but there are a lot of malloc(3)'s out there that don't bother 
to munmap or sbrk(-) the heap (so that memory never actually gets freed
by the process, let alone the kernel).

as you point out, the vm_map_clip_start/vm_map_clip_end is going to
muck with the object reference counts.


chuck