eli@PWS.BULL.COM (Steve Elias) (10/30/90)
problem: the X.Desktop supplied with SCO Unix seems to cause the SCO X server to grow by leaps and bounds if it is iteratively driven with a shell script which does "tellxdt" commands causing directory windows to be opened and closed repeatedly. (scripts appended below.) the original metric by which we observed this problem was the cycle time through one of these "tellxdt" shell scripts. the behavior is such that the elapsed time through the script goes from 30 seconds at startup, to over an hour after a day or so of running (on 386 or 486 SCO Unix v3.2 -- not the 'new' kernel, btw). this behavior occurred with VGA, Microfield, and hercules-mode X servers on SCO. with the Microfield system, we observed the size of the X server itself. it grows by bizarre and enormous spurts; the X server grows from 1M to over 10M of virtual memory in a matter of minutes, observed via the output of a "ps -ealf". we have not tried to directly observe the X server memory growth on the VGA and hercules systems, though it seems likely that such growth is indeed the cause of the progressive slowness of these systems as well. future tests will confirm this... (imho). now, onto the HP angle. we tried a new test today: telling the SCO X.desktop to send its output to an HP workstation X screen. the HP X server is growing, slowly but surely -- by about 1K per minute. this is a far cry from the megabytes per minute growth we observed with the SCO microfield X server, but it's still interesting. known bugs in Motif 1.0 can probably account for this slow growth of the HP X server. (the Motif 1.0 "memory leak" bugs.) in the last 2 hours, the HP X server has grown from 656k to 717k. as i mentioned, the SCO X server grows MUCH faster than this, at a rate which looks like some sort of quantized exponential. i don't know how to account for the leaps-n-bounds massive growth of the X server on the SCO system. the only possibility i can think of for the moment is a vast bug in the SCO X server source -- perhaps the source which SCO supplies to it's 3rd party display driver folks. if you've got any feedback on this problem, please get back to me. i don't read the comp.windows.x.* group, but i figure that there will be readers there who have opinions on this bizarre X server behavior. tests we're gonna run Real Soon Now: -- direct observation of the X server memory growth on an SCO system with VGA card instead of Microfield. -- a manual test which duplicates the "tellxdt" script, but which is all done by hand with the mouse. this will take a while, since i'm a clumsy mouse operator. i'll be very surprised if this behavior does not occur when the X.desktop is driven manually rather than via tellxdt. thanks in advance for your comments, questions, and especially your patience and curiosity if you've read this far... peace! /eli the shell scripts: #!/bin/csh -f /* this script is "xdt.short" */ tellxdt ddw /bin tellxdt ddw / tellxdt ddw /tmp tellxdt btf /bin tellxdt btf /tmp tellxdt btf / tellxdt btf /bin tellxdt close_directories #!/bin/csh -f /* this script is "xdt.goshort" */ @ count = 0 while 1 @ count = $count + 1 echo $count " \c" time csh -f xdt.short ps -ealf | grep " X " | grep -v grep | cut -c 45-90 end ; Steve Elias, eli@pws.bull.com; 617 932 5598 (voicemail) ; 508 294 0101 (SCO Unix fax) ; 508 294 7556 (work phone)