Subject: Re: (not-so) interesting observations on the Xsun(Mono) Xserver problem....
To: NetBSD-current Discussion List <current-users@NetBSD.ORG>
From: Greg A. Woods <woods@weird.com>
List: port-sparc
Date: 05/07/2002 15:41:18
[ On , May 7, 2002 at 12:18:24 (-0700), Wolfgang Rupprecht wrote: ]
> Subject: Re: interesting observations on the Xsun(Mono) Xserver problem....
>
> Could your server be growing to unreasonable levels?
No, not likely. It doesn't live that long! ;-)
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
woods 12477 24.5 0.5 4620 188 ?? SN 1:41PM 12:57.24 XsunMono :0 -fp /usr/X
The very largest core I've ever got is, I think, this one:
text data bss dec hex filename
0 10117464 0 10117464 9a6158 XsunMono.core
The core from after three full days of operation over the weekend was no
bigger than normal:
text data bss dec hex filename
0 4419928 0 4419928 437158 XsunMono.core
There's still 10MB free on the system -- it doesn't usually page (I'd
notice that since it pages via NFS over 10baseT).
After six days uptime (and 8 Xserver crashes) it's only paged a tiny bit
and most of that is stuff that's never in the current working set:
$ /sbin/swapctl -l
Device 512-blocks Used Avail Capacity Priority
/swap/very 131072 5944 125128 5% 0
My guess about libungif didn't seem to be going anywhere useful either.
I've had three crashes since I posted and I've not run anything at all
extraordinary before the last crash..... :-(
So, that's one definite problem with a UTF-8 encoded font eliminated,
and libungif's potentially bad behaviours eliminated, and 1.5W problems
also either eliminated or still lingering unresolved. Looks like I've
gone back to "Go" without collecting $200. Again. :-(
Perhaps I'll get ambitious and try the 1.5ZC kernel again, but this time
I'll re-build gdb too so that I can at least look at the new core files.
--
Greg A. Woods
+1 416 218-0098; <gwoods@acm.org>; <g.a.woods@ieee.org>; <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>