Xref: utzoo comp.sys.3b1:164 comp.sys.att:11729 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!texsun!letni!mic!ernest!shibaya!afc From: afc@shibaya.lonestar.org (Augustine Cano) Newsgroups: comp.sys.3b1,comp.sys.att Subject: Re: Unix pc sluggishness when switching windows Summary: wmgr is the problem, and it's serious! Message-ID: <1991Feb7.161712.9239@shibaya.lonestar.org> Date: 7 Feb 91 16:17:12 GMT References: <1991Feb5.040416.354@shibaya.lonestar.org> <979@gnosys.svle.ma.us> Organization: Multidisciplinary Designs Unlimited Lines: 37 In article <979@gnosys.svle.ma.us> gst@gnosys.svle.ma.us (Gary S. Trujillo) writes: >In <1991Feb5.040416.354@shibaya.lonestar.org> afc@shibaya.lonestar.org (Augustine Cano) writes: > >> So, what is slowly degrading in the kernel that is fixed at boot time? >> Has anybody else noticed this? Does anybody have a clue as to what it is? > >Yup. It's a memory leak of some sort in the window manager. Do a "ps -el" >and take a look at the memory size numbers | > v > 1 S 0 17268 1 3 27 20 14d 18: 13 5af68 w4 2:36 wmgr > >I just killed and restarted wmgr recently, so not much memory has been >consumed so far (I've seen the first number as high as 80 or 90). Let's >see what I get if I kill and restart wmgr again: > > 1 S 0 20490 1 6 27 20 1e5 6: 12 5af68 w4 0:04 wmgr > >Maybe one of the UNIXpc development team out there who have access to >the source code of wmgr can take a look for us. I've just learned to >kill and restart wmgr every 2 or 3 days. This is not a leak, it's a FLOOD! I just hit the button 24 times and that was enough to bump the memory size by 1. Please, somebody with source, would it be possible to either get a patch to fix this or to store a fixed binary version at osu? >Gary > >-- > Gary S. Trujillo gst@gnosys.svle.ma.us >Somerville, Massachusetts {wjh12,bu.edu,spdcc,ima,cdp}!gnosys!gst -- Augustine Cano INTERNET: afc@shibaya.lonestar.org UUCP: ...!{ernest,egsner}!shibaya!afc