On Mon, 3 Mar 2008 23:56:36 -0600 "Paul Johnson" <[EMAIL PROTECTED]> babbled:
> On Mon, Mar 3, 2008 at 10:02 PM, The Rasterman Carsten Haitzler > <[EMAIL PROTECTED]> wrote: > > On Mon, 3 Mar 2008 13:06:45 -0600 "Paul Johnson" <[EMAIL PROTECTED]> > > babbled: > > > > 11:40AM ~/.e/e/backgrounds > pwd > > /home/raster/.e/e/backgrounds > > 11:40AM ~/.e/e/backgrounds > /bin/ls *.edj | wc -l > > 100 > > 11:40AM ~/.e/e/backgrounds > for I in *.edj; do enlightenment_remote > > -default-bg-set $HOME/.e/e/backgrounds/$I; sleep 1; done; > > enlightenment_remote -default-bg-set "" > > > > [... wait for it to set all 100 and go back to theme default...] > > > > Hey, Raster. > > It is really nice of you to answer these messages. > > I think you probably have some quality control problems over the > sprawling empire of E. The window manager itself is stable, but these > addon components that fall into the enlightenment process appear to > offer no end of user suffering. Like the weird CPU problem I had with > the battery status module, or this mysterious memory problem. People > are going to keep cropping up, thinking that E is messed up, but > rather it is these addons that E seems to open itself up for. Can't > you force these things to run under a different process number, so > that they are easier to trace? Hell, that battery monitor problem was > caused by an outdated config file from a previous version of the > battery module, and I don't have any way to be sure what caused the > memory leak. you literally can't. if you don't want it in e - then write an app. modules are for extending e - when you need to extend e. they are not a generic programming system for people to write things. the default modules s ships with (in e's own src that build when u build e) are fine. anything in e_modules ou use at your own risk. there is nothing that can be done. you can't run them in another process id as they then are not part of the e process and have no access or control over e. adding those controls would need an ipc mechanism (dbus, ecore_ipc etc.) and then everything has to be exported via that. even then they can cause leaks in e as they ask E to allocate resources for them. the reason modules are in an entirely separate cvs module (not even in the e17/ tree) *IS* quality control. they are not even part of e17 and are separated out. it is up to the authors of those modules to maintain them. if users insist on using them just because they are there - then there is nothing i can do beyond deleting them entirely. i say it repeatedly. if you see crashes or leaks - first remove all modules that did not ship with e itself "out of the box". anything u added later from other sources (e_modules from cvs or tarballs or whatever) could be suspect. some might be just fine, some may not be. some have done all there is to be done quality-control wise. it is technically not possible to split them out into separate processes. modules as a design paradigm just precludes it. a lot of "modules" are stupid. they should never have been modules. they should be whole applications on their own. some of those should only have some of their stuff in e as a module and the rest should be in a separate process they run (like temperature, battery and cpufreq modules run tempget, batget and cpufreq executables to do the work. battery just had its core moved to a separate process). > But, I definitely agree with you it is not in E itself. > > Today I logged in and did nothing. Did not change any backgrounds and > watched top. This sequence of top reports was collected during 5 > minutes of doing nothing. Watch the memory grow: > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 14191 pauljohn 20 0 199m 148m 5924 S 1 14.7 0:16.30 enlightenment > > > 14191 pauljohn 20 0 310m 238m 5956 S 1 23.6 0:27.31 enlightenment > > 14191 pauljohn 20 0 360m 277m 5956 S 1 27.5 0:31.47 enlightenment > > 14191 pauljohn 20 0 489m 378m 6004 S 49 37.5 0:44.27 enlightenment > > 14191 pauljohn 20 0 560m 432m 5940 S 6 42.9 0:54.21 enlightenment > > After I saw your post warning memprof and cautioning about modules, I > opened up the E configuration panel, advanced-> modules, and kept > removing them, one by one, thinking memory use would go down. But it > did not. I cleared about 20 of those puppies. No result. some module may not have shut itself down and have a timer or something running still allocating resources. > Then I remembered to E DR13 days, when a E restart was necessary, and > VOILA. No more memory leak. After an E restart, top shows the memory > leak is gone. > > 14191 pauljohn 20 0 44964 14m 5056 S 0 1.4 1:05.14 enlightenment > > I removed a bunch of modules before I realized I needed a re-start. > They were dropshadow, ibar, ibox, tclock, battery, cpu, temperature, > windowlist. So I can't tell you all of the ones that leak memory. those should be fine - except maybe tclock. those are core modules. > But I can say FOR SURE that the "taskbar" module leaks like crazy. > The second I re-enable that one, and the memory usage climbs back up > within a minute > > 14191 pauljohn 20 0 127m 80m 5896 S 9 7.9 1:22.36 enlightenment > > Well, another module bites the dust. I'm certain that I did have a > completely clean ~/.e just three days ago, so this is not due to a > config file from E DR16 or such lingering about. > > And I seriously would urge you to find some way to differentiate E's > reputation from all of these modules that are floating about with E. > I've only been back trying E for 1 week, but during the time I've had > these two pretty serious module related troubles. i know. i have mulled over the idea of having "signed" modules of some sort, though due to it all being open source, anything can be mimicked to pretend to be "signed". but unsigned (not quality assured) modules would give you a big warning when enabling them. that's the best we can do. right now the best i can do is literally hard-code a list of module names known to be "good" in e and anything else gets a warning box, until such a time as they are known to be safe and well done and then in a subsequent release this list gets expanded. but really - as i said above. these modules are separated. u have to go to extra effort to get them specifically. > -- > Paul E. Johnson > Professor, Political Science > 1541 Lilac Lane, Room 504 > University of Kansas > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > enlightenment-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
