On Thu, 25 May 2006 03:27:30 +0200, Arnt wrote in message <[🔎] 20060525032730.6096bfbd.arnt@c2i.net>: > On Wed, 24 May 2006 17:28:27 -0700, Steve wrote in message > <20060525002827.GD27893@mauritius.dodds.net>: > > > reassign 367986 xserver-xorg > > thanks > > > > On Tue, May 23, 2006 at 04:50:23PM +0200, Arnt Karlsen wrote: > > > On Sun, 21 May 2006 19:34:16 -0700, Steve wrote in message > > > <20060522023416.GH6941@mauritius.dodds.net>: > > > > > > On Mon, May 22, 2006 at 03:32:14AM +0200, Arnt Karlsen wrote: > > > > > On Sun, 21 May 2006 17:55:12 -0700, Steve wrote in message > > > > > <20060522005512.GA6941@mauritius.dodds.net>: > > > > > > > > Any crash in X is not itself a bug in sylpheed-gtk1 either, > > > > > > *unless* sylpheed-gtk1 is allocating an excess of > > > > > > server-side memory and triggering the kernel's OOM killer, > > > > > > which doesn't seem likely. > > > > > > > ..ok, how do I help you find out? Running it locally, has it > > > > > crash X a lot, and get X get sluggish and I see loads around > > > > > 2 to 6. Running it over ssh, I see nice low loads, around > > > > > 0.05-0.15. > > > > > > The xrestop program from the package of the same name should > > > > tell you whether this is a case of large amounts of memory (or > > > > increasing amounts of memory) are being eaten on the server by > > > > sylpheed. > > > > > ..ideas on how to make xrestop survive to capture crash data? > > > I ssh -X it, and xrestop crashes too, and the ssh link is trashed > > > and needs resetting. > > > > Nope, I fully expect xrestop to crash when the X server disappears. > > The thing would be to look for any growth in memory usage *while* > > sylpheed is beginning to become sluggish. > > ..ok, about 50% up to 140kB. > > > > Neither xrestop nor sylpheed-gtk1 reports its pid to it, and > > > I get at least 6 <unknown>'s showing up. > > > > > xrestop - Display: 192.168.1.33:0.0 > > > Monitoring 23 clients. XErrors: 42 > > > Pixmaps: 47115K total, Other: 109K total, All: > > > 47225K > > > total > > > > > res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID > > > Identifier 1800000 35 12 1 23 83 24602K 4K > > > > > > > Any chance you could provide this xrestop output without line > > wrapping? > > ..attached hereto: > arnt@a45:~ $ ll /tmp/xrestop.on.ssh && md5sum /tmp/xrestop.on.ssh > -rw-r--r-- 1 arnt arnt 2065 May 23 15:47 /tmp/xrestop.on.ssh > 2f16a91e0c5638da8ad7eb39df812707 /tmp/xrestop.on.ssh > arnt@a45:~ $ > > > > ..sylpheed-gtk1 running locally is waaaaaaaaaay more sluggish > > > than 140kB warrants. Running remotely, it's quick 'n snappy. > > > > Well, if xrestop doesn't show any unusual memory usage, how about > > just 'top'? > > ..aye, did that too, and it showed xrestop loading up. Running > sylpheed-gtk1 remotely, I see no problems and even up 18fps in > a Flightgear session at 1600x1200x24bpp on a 2048x1536x24bpp > KDE-3.5.2-2 on this 7yr old amd k6-2 450MHz rig, ok 1.5 yr old > ATI 9250 clone, RV280|5960 chip, on a X-7.0.0 radeon driver. ..and remembering I had left in running, I now see 12.6% memory usage by Sylpheed-gtk1, thats off 384MB ram and 1.5GB swap: -rw-r--r-- 1 arnt arnt 31168 May 25 03:54 /tmp/top.on.ssh 5f4edaab6ff45881e6386589d301359b /tmp/top.on.ssh arnt@a45:~ $ qalc .126*384 0.126 * 384 = 48.384 #assuming no swap use. And there is still plenty omph left in this dinosaur, even when running FlightGear, it _is_ a resource hog. ;o) ..arnt@a45:~ $ ll /tmp/w.free && md5sum /tmp/w.free -rw-r--r-- 1 arnt arnt 726 May 25 04:13 /tmp/w.free 35f5d14d39a51a9bb8354936e7c825a0 /tmp/w.free > > Anyway, 140KB is definitely not going to be a reason for the X > > server to crash, so let's reassign this to the xserver now. > > ..whatever does the job. :o) > > ..could it be a font thing? These crashes started after the font I > had set up for Sylpheed-gtk1, disappeared off this box, everything > else works like it should, AFAICT. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case.
Attachment:
top.on.ssh
Description: Binary data
Attachment:
w.free
Description: Binary data