osso-statusbar-cpu Re: Beware "Personal launcher"
Santtu Lakkala wrote: > Frantisek Dufka wrote: >> osso-statusbar-cpu does exactly this. With memory reporting turned off >> it is nice statusbar clock with black background. Once the background >> turns solid blue you know there is a problem :-) > > Actually it should have graphs of cpu and/or memory usage, not black > background; there's just a bug I haven't fixed that causes it to be > black by default. If you change the settings, it should start to work. > Sorry for the confusion, it does have graph of CPU usage. I don't see any bug. I meant that in normal case CPU usage is pretty low so it is mostly black. BTW long time ago I got chinook version from http://people.debian.org/~tschmidt/maemo/chinook/osso-statusbar-cpu/ Yesterday I noticed there is also 0.7.x (since June 2008) with 'official' chinook support in maemo-hackers.org repository http://maemo-hackers.org/apt/pool/main/o/osso-statusbar-cpu/ Both of them work fine, they just look different. With default OS2008 theme I like a bit more the old 0.6.1 look with thin border :-) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beware "Personal launcher"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frantisek Dufka wrote: > osso-statusbar-cpu does exactly this. With memory reporting turned off > it is nice statusbar clock with black background. Once the background > turns solid blue you know there is a problem :-) Actually it should have graphs of cpu and/or memory usage, not black background; there's just a bug I haven't fixed that causes it to be black by default. If you change the settings, it should start to work. - -- Santtu -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkq3l0ACgkQX9Rc0+po4p1GZwCgpyS/0IlERxAzpEUSTS+RV0HV DskAnj/9VF6ZqZP+KGFHkkS8LBqeU1A1 =9NjT -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beware "Personal launcher"
Till Harbaum / Lists wrote: > Unfortunately there's no fan on the n8x0 becoming noisy if the device is under > heavy load. So even a simple thing like a taskbar icon indicating a high cpu > load and being able to present something similar to the windows task manager > might help. osso-statusbar-cpu does exactly this. With memory reporting turned off it is nice statusbar clock with black background. Once the background turns solid blue you know there is a problem :-) http://inz.fi/blog/category/geeky/maemo/maemo-hackers/osso-statusbar-cpu/ Chinook build works in diablo too http://people.debian.org/~tschmidt/maemo/chinook/osso-statusbar-cpu/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beware 'Personal launcher'
Hi, ext Niels Breet wrote: >> Asked for more details: >> 1. Only personal launcher is enabled and device is booted after >> enabling it 2. "Use resizable layout" enabled >> 3. Launcher has enough icons (in one column, icon size = 64) >> that it it's higher than screen >> >> When launcher is disabled, Desktop crashes. The leakage and >> crash are 100% reproducible. > > The author was able to reproduce your leak with these instructions. He > uploaded a new version to Extras to solve the problem. > > Can you confirm that it is fixed now? It's not anymore refreshing/resizing itself constantly when larger than screen (which with the redraw leak caused the issue and made it easily to crash when it was disabled). I.e. the main issue is solved. The redraw leak is still there though. It can be tested easily just by running: mem-monitor-smaps -p $(pidof hildon-desktop|cut -d' ' -f1) And dragging with stylus the bottom-right resize handle back and forth. Resizing should normally happen fairly rarely though, so this isn't as critical. Btw. The setup application seems to throw some asserts when it's used: From setup startup: personal-launcher-setup[10388]: GLIB CRITICAL ** GLib - g_strcasecmp: assertion `s1 != NULL' failed From opening Settings dialog: personal-launcher-setup[10388]: GLIB CRITICAL ** Gtk - gtk_box_pack_start: assertion `child->parent == NULL' failed - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beware 'Personal launcher'
On Fri, November 21, 2008 09:30, Eero Tamminen wrote: > Hi, Hi, > > ext Niels Breet wrote: >>> For some strange reason its memory usage evened out after it's eaten >>> about all there is. It's possible that there was some triggering >>> condition for this, I don't know. >>> >> I have installed and tested the application on my tablet and I really >> can't trigger the behavior. >> >> What did you do to trigger this condition? Did you overlap applets? Did >> you install other applets? Can you reproduce it on a fresh firmware? > > Asked for more details: > 1. Only personal launcher is enabled and device is booted after > enabling it 2. "Use resizable layout" enabled > 3. Launcher has enough icons (in one column, icon size = 64) > that it it's higher than screen > > When launcher is disabled, Desktop crashes. The leakage and > crash are 100% reproducible. > The author was able to reproduce your leak with these instructions. He uploaded a new version to Extras to solve the problem. Can you confirm that it is fixed now? > > - Eero > -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beware "Personal launcher"
Hi, Am Donnerstag 20 November 2008 schrieb Eero Tamminen: > Could this be kicked out of extras so that people don't "launch" their > devices to oblivion? Just as a side note: I recently had this problem with the osso rss reader. It took me some time to figure out that it was the rss feed reader eating my battery with a 100% cpu load even after a reboot (i was in fact already searching for a cheap replacement battery on ebay). Deleting the rss feed folder under /home/user resolved my problem. I didn't even remember that i ever used and i am not using the rss home applet. So i was pretty surprised to see it running at all ... not to mention the 100% cpu load it did ... I am not saying this to blame anyone. Instead i am saying that this hasn't anything to do with the extras repo. You just cannot prevent these things. I also think like already suggested here that the solution is some monitoring mechanism. If one of those units has a process running at 100% cpu load for more than a few minutes there's sure something going wrong. So this is IMHO the only way address the problem. Unfortunately there's no fan on the n8x0 becoming noisy if the device is under heavy load. So even a simple thing like a taskbar icon indicating a high cpu load and being able to present something similar to the windows task manager might help. People are used to this task manager, so it should be possible to have them using it. But then again in my case they still need to be able to prevent the rss reader from doing the same again after the next reboot ... Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beware 'Personal launcher'
> The answer is not testing of things being put into Extras > > The answer for the community repository is a feedback mechanism, both for > packages themselves, and for contributors. We need to create an easy way for > people to provide feedback on the apps they install from Extras and for > people to see the feedback level of both the app and the contributor before > they install it. Agreed that individual testers gatewaying extras is a bad idea. Some alternate proposals... 1) Require an application to spend some period of time in extras-devel without a major bug submission before promotion. This wouldn't require technical enforcement, just a clear guideline for package-owners to follow. If package-owners behave irresponsibly, the bug-wrangler or some similar role could chastise them and point them to the promotion guidelines. 2) Create a guideline for when a package should be demoted to extras-devel based on negative user feedback. Using the recent personal launcher thread as an example, if an applet really does have a crash/reboot bug, it's filed in bugzilla, confirmed, and ignored for some period of time, that applet probably shouldn't be in extras. That's an extreme example, and in order to prevent frustration the guidelines for demotion must be very clear, and very strictly adhered to. Leaving garbage, buggy, unmaintained apps in the end-user repo is bad juju, but so is pulling well-maintained apps just because they have a serious bug that happens to be found by a high-profile community member (not to pick on Eero who a huge amount of amazing work, but if someone else had found that bug demoting the app would never have been considered at all). Thanks, Mike ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beware 'Personal launcher'
On Friday 21 November 2008 08:30:19 Eero Tamminen wrote: > > I talked to the author. He used your mem-testing scripts and valgrind and > > couldn't reproduce it either. Nor did he receive any complains from the > > about 11000 downloads he had. > > Now that I was demonstrated the issue[1], I have to admit that the > applet configuration was pretty unusual and it's unlikely that people > would leave the applet enabled configured like that. This is exactly why I do not think that any attempts on quality control of Extras are feasible (or even desirable). I am sure everything in Extras has some bugs -- but some have more (or more serious) bugs than others. The answer is not testing of things being put into Extras: that would take a lot of resources, is not scalable and will give rise to false positives and negatives (the tester is the one person in 11,000 who hits a bug and refuses entry, or the tester does not hit the bug and gives a false sense of security). Of course, if Nokia decided it was worth assigning some QA resource and having a repository of software tested to Nokia quality levels that would be fine. But it would be separate from the community repository. The answer for the community repository is a feedback mechanism, both for packages themselves, and for contributors. We need to create an easy way for people to provide feedback on the apps they install from Extras and for people to see the feedback level of both the app and the contributor before they install it. It wouldn't be perfect (there may be a really nasty bug that only affects 10% of people) but it would be much better than what we have today and much better than attempting to impose a quality gate Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beware 'Personal launcher'
Hi, ext Niels Breet wrote: >> For some strange reason its memory usage evened out after it's eaten >> about all there is. It's possible that there was some triggering condition >> for this, I don't know. >> > I have installed and tested the application on my tablet and I really > can't trigger the behavior. > > What did you do to trigger this condition? Did you overlap applets? Did > you install other applets? Can you reproduce it on a fresh firmware? Asked for more details: 1. Only personal launcher is enabled and device is booted after enabling it 2. "Use resizable layout" enabled 3. Launcher has enough icons (in one column, icon size = 64) that it it's higher than screen When launcher is disabled, Desktop crashes. The leakage and crash are 100% reproducible. 2&3 seems to be the cause for this. It seems that the resize stuff in the applet is broken and the constant applet flicker is a symptom of this bug: - I think the applet leaks on each resize - It doesn't stop resizing when the area doesn't fit into screen (the area size could be limited to the screen) - Resizing doesn't handle applet unload correctly (disabling happening when applet resizes) Also, making icon size smaller after this so that things fit into screen doesn't help, the applet size allocation remains still higher than screen (can be seen from the flickering and when dragging the applet) i.e. it still leaks & crashes. > I talked to the author. He used your mem-testing scripts and valgrind and > couldn't reproduce it either. Nor did he receive any complains from the > about 11000 downloads he had. Now that I was demonstrated the issue[1], I have to admit that the applet configuration was pretty unusual and it's unlikely that people would leave the applet enabled configured like that. (And the applet seems pretty nice, I might starting to use it myself.) - Eero [1] Note to myself. Always check things yourself. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beware "Personal launcher"
On Thu, 2008-11-20 at 17:17 +0200, Eero Tamminen wrote: > Hi, [...] > Could this be kicked out of extras so that people don't "launch" their > devices to oblivion? Calm down - this is not the app store (at least I hope so) Get in touch with the author and fix the problem in a dialog. -- Michael Flaig <[EMAIL PROTECTED]> PROLinux.de signature.asc Description: This is a digitally signed message part ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Beware 'Personal launcher'
I can't reproduce it - works fine. Nick. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Niels Breet Sent: Friday, November 21, 2008 04:34 To: Eero Tamminen Cc: maemo-developers@maemo.org Subject: Re: Beware 'Personal launcher' On Thu, November 20, 2008 17:59, Eero Tamminen wrote: > Hi, Hi, > > > For some strange reason its memory usage evened out after it's eaten > about all there is. It's possible that there was some triggering > condition for this, I don't know. > I have installed and tested the application on my tablet and I really can't trigger the behavior. What did you do to trigger this condition? Did you overlap applets? Did you install other applets? Can you reproduce it on a fresh firmware? I talked to the author. He used your mem-testing scripts and valgrind and couldn't reproduce it either. Nor did he receive any complains from the about 11000 downloads he had. > > - Eero > -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beware 'Personal launcher'
On Thu, November 20, 2008 17:59, Eero Tamminen wrote: > Hi, Hi, > > > For some strange reason its memory usage evened out after it's eaten > about all there is. It's possible that there was some triggering condition > for this, I don't know. > I have installed and tested the application on my tablet and I really can't trigger the behavior. What did you do to trigger this condition? Did you overlap applets? Did you install other applets? Can you reproduce it on a fresh firmware? I talked to the author. He used your mem-testing scripts and valgrind and couldn't reproduce it either. Nor did he receive any complains from the about 11000 downloads he had. > > - Eero > -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beware "Personal launcher"
Hi, ext Tuukka Tolvanen wrote: > fwiw, I don't think reporter-verifiability is enough of a concern here > to not file bugs -- people finding out about issues seems more > important. I agree on principle, but I don't like to report bugs I haven't encountered myself (I cannot answer questions and unfortunately I don't have time for checking 3rd party stuff, somebody actually using the thing needs to do that). > (provided your source is good enough for confident > reporting, which it must be, given this thread) Yes. >> It's leaking 8MB/min, updates screen constantly even when screen is >> blanked and crashes desktop when disabled. Project with this bad QA >> should IMHO just be kicked out of extras. > > 8MB/min *blink*?! That's ...not that many minutes :) For some strange reason its memory usage evened out after it's eaten about all there is. It's possible that there was some triggering condition for this, I don't know. - Eero "Hello buggy, have you seen my shiny new bugzapper?" ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beware "Personal launcher"
(Oops, I suck at reply-all in gmail, apparently.) Eero Tamminen <[EMAIL PROTECTED]>: >>> Just noticed that "Personal launcher" applet (latest v0.6-4 in extras) >>> leaks like mad and updates the screen uselessly at high frequency. >>> >>> Because it's an applet within the Desktop process which allocations are >>> guaranteed, it will cause device to run out of memory very soon. Result >>> is that other applications start aborting and device will slow down to >>> crawl. Constant screen updates (even when screen is blanked) drain >>> the battery. >>> >>> Could this be kicked out of extras so that people don't "launch" their >>> devices to oblivion? >> >> I guess it would be preferable, if possible in a timely manner, for it >> to be kicked out by an updated version that doesn't misbehave > > It's leaking 8MB/min, updates screen constantly even when screen is > blanked and crashes desktop when disabled. Project with this bad QA > should IMHO just be kicked out of extras. 8MB/min *blink*?! That's ...not that many minutes :) > (Personally I'd like there to be some kind of quick testing before > things get into extras.) > >> -- but I >> don't see a bugreport on the issue in the project's garage (alas) >> tracker. *nudge* > > I didn't try this myself and I'm not using it myself so I couldn't > verify the fix. fwiw, I don't think reporter-verifiability is enough of a concern here to not file bugs -- people finding out about issues seems more important. (provided your source is good enough for confident reporting, which it must be, given this thread) 't. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beware 'Personal launcher'
Hi, ext Niels Breet wrote: >> Just noticed that "Personal launcher" applet (latest v0.6-4 in extras) >> leaks like mad and updates the screen uselessly at high frequency. >> >> Because it's an applet within the Desktop process which allocations are >> guaranteed, it will cause device to run out of memory very soon. Result is >> that other applications start aborting and device will slow down to crawl. >> Constant screen updates (even when screen is blanked) drain >> the battery. >> >> Could this be kicked out of extras so that people don't "launch" their >> devices to oblivion? >> > > I've sent the author a mail. Let's see if he responds and fixes the issue. > > As we have never had a case where we needed to do a 'demotion', I really > think we need to setup some procedures for this. Let's discuss what we > should do in cases like this. Ideally there should be some quick memory leakage testing done[1] before something enters into extras, at least if it's an applet or otherwise always running. - Eero [1] E.g. using mem-monitor from sp-memusage package in tools repo. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beware 'Personal launcher'
On Thu, November 20, 2008 16:17, Eero Tamminen wrote: > Hi, Hi, > > Just noticed that "Personal launcher" applet (latest v0.6-4 in extras) > leaks like mad and updates the screen uselessly at high frequency. > > Because it's an applet within the Desktop process which allocations are > guaranteed, it will cause device to run out of memory very soon. Result is > that other applications start aborting and device will slow down to crawl. > Constant screen updates (even when screen is blanked) drain > the battery. > > Could this be kicked out of extras so that people don't "launch" their > devices to oblivion? > I've sent the author a mail. Let's see if he responds and fixes the issue. As we have never had a case where we needed to do a 'demotion', I really think we need to setup some procedures for this. Let's discuss what we should do in cases like this. > > - Eero -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
