On Sun, 21 Nov 2010 18:36:51 +0100, Kim Woelders <[email protected]> wrote:
> On Sun, 21 Nov 2010 17:51:37 +0100, Kim Woelders <[email protected]> wrote: > >> On Sat, 20 Nov 2010 17:38:07 +0100, Dennis Nezic >> <[email protected]> wrote: >> >>> On Sat, 20 Nov 2010 09:15:35 -0500, Dennis Nezic wrote: >>>> On Sat, 20 Nov 2010 12:59:40 +0900, Carsten Haitzler (The Rasterman) >>>> wrote: >>>> > On Fri, 19 Nov 2010 22:07:59 -0500 Dennis Nezic >>>> > <[email protected]> said: >>>> > >>>> > xrestop >>>> > >>>> > use that to see if anythingis leaking x resources. other than that >>>> > it may simply be normal glibc memory growth. look at rss not vsize >>>> > for an accurate picture - vsize is not relevant, also it could be a >>>> > server leak of some sort - if xrestop doesnt show some client eating >>>> > through lots of pixmaps/gc's or something. report to your distro or >>>> > xorg. >>>> >>>> Very cool! As I suspected, e16 is by far the largest consumer. After >>>> about 4 days of e16 uptime, I have: >>>> >>>> res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID >>>> Identifier 0400000 4075 3 1 176 538 85687K 109K >>>> 85796K ? e16 >>> >>> The main culprit that I see, so far, are the menus. Here are a few >>> consecutive xrestop iterations, while simply opening my APPS_SUBMENU >>> menu (which has no submenus). (The first column is Wins -- 9 get >>> created each time I open the menu, but only 8 get freed after closing >>> it.) >>> >>> 4268 3 1 253 449 94373K 111K 94485K ? e16 >>> 4269 3 1 291 449 95913K 111K 96024K ? e16 >>> 4270 3 1 274 449 96373K 111K 96485K ? e16 >>> 4271 3 1 289 448 97074K 111K 97186K ? e16 >>> >>> Here is the same while opening my ROOT_2 menu, which has a few >>> submenus, that I didn't open. (88 Wins get created, only 15 get >>> removed, thus "leaking" 73 each time.) >>> >>> 4531 3 1 282 471 104569K 118K 104687K ? e16 >>> 4604 3 1 286 470 105843K 119K 105963K ? e16 >>> 4677 3 1 278 470 106813K 121K 106935K ? e16 >>> 4750 3 1 282 470 108113K 123K 108236K ? e16 >>> 4823 3 1 284 471 109331K 125K 109456K ? e16 >>> >>> I also find that when programs crash, not all the Wins or memory get >>> released. >>> >>> (I should correct my original report -- the memory does sometimes >>> decrease -- but obviously the general trend is always increasing.) >>> >> This definitely doesn't look right. It certainly looks like there is a >> window (and pixmap memory) leak. >> >> The number of windows used by menus should not increase after repeated >> opening of the same menu, but after closing the menus are kept around >> for >> 5-10 minutes so it will take about that long for resource usage to go >> down >> to the level before the menu was first shown (this is how it is supposed >> to work, anyway). >> >> I wonder about e16 resources not being freed when an application >> crashes. >> That definitely shouldn't happen either. >> >> FWIW I don't see any of this weirdness... >> >> Could you please send me the output from "xwininfo -root -tree"? >> >> Which e16 version is this? >> > Never mind - On another box I get resource leakage when using menus too. > Not when apps crash though. > The menu resource leakage problem exists in 1.0.5 and 1.0.6, but not in 1.0.4 or 1.0.7. So, it seems to have been fixed along with other menu related problems in 1.0.7 :) /Kim ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
