On Sun, 21 Nov 2010 19:10:48 +0100, Kim Woelders wrote:
> 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 :)

Indeed -- 1.0.7 works! Thanks again! (Apologies for not mentioning my
1.0.6 version earlier.)


------------------------------------------------------------------------------
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

Reply via email to