(In reply to comment #0)
> EXTRA SOFTWARE INSTALLED:

This is particularly relevant for this type of bug, please list all desktop
widgets at least.

widgets im running.

-Dataplan Monitor
-IP address
-media player
-eyes
-OMweather
-Phone recorer (replay)
-FM transmitter boaster
-FM transmitter switch
-Search box

FYI. I ran into this problem when I replaced a bunch 15-20 of icons (png) files
in /usr/share/icons/hicolor/64x64/hildon with some slightly (5-8k) larger ones.
and then added shortcuts to them on a homepage.. The problem only went away
when I compressed the PNG files.

I believe there is a  very very low memory limit for hildon-desktop which can
be reached by
- replacing icons with larger ones
- installing many new apps and then adding shortcuts to them one home pages

*** This bug has been confirmed by popular vote. ***

Some additional info: my phone becomes very slow and relatively unresponsive
after a few days of use.  By unresponsive I mean that it can take seconds (4-5)
for the task manager to show up or even for the phone to wake from sleeping
(2-3 sec) and I've missed phone calls because the screen just wouldn't show up
in time.  This happens even if very few apps running but is quite intermittent
and hard to reproduce.  When the phone is experiencing such slowdowns music
playback stutters when browsing or switching windows or launching an app. 
Starting the camera takes forever.  A reboot seems to fix this problem but
closing all applications does not.

This cannot be reproduced just by launching a lot of applications.  After a
fresh reboot the phone will be very responsive for a while but after a day or
two (or more, not sure really), also with browser windows left on overnight, it
starts to act this way even if I close all running applications.

To address this I've tried disabling the following widgets:

ap news
conversation inbox
FM transmitter on/off
personal IP

and still have the following widgets running:

dataplan monitor
desktop media player
desktop load monitor
calander
forcea weather

Since disabling the first set of widgets above and restarting the phone (a day
ago) its been very responsive and hasn't had the same problems but its only
been one day.  Will report back if the issue returns or not.

Please feel free to contact me with questions.

See also threads:

http://talk.maemo.org/showthread.php?t=42500
http://talk.maemo.org/showthread.php?t=42960

(In reply to comment #0)
> The issue: Hildon-home shows as consuming 96% cpu and 47% ram from time to time
> (using conky, htop).

Is "ram" the "MEM%" column in htop?  If so, that refers to the entire virtual
memory, ie hildon-home was using approximately twice the size of your physical
RAM so the system was thrashing.

If this happens again, can you attach /proc/PID/smaps (where PID is the process
ID of the memory hog hildon-home process)?

(In reply to comment #2)
> widgets im running.
> [...]
> -IP address

(In reply to comment #5)
> To address this I've tried disabling the following widgets:
> [...]
> personal IP
>
> Since disabling the first set of widgets above and restarting the phone (a day
> ago) its been very responsive and hasn't had the same problems but its only
> been one day.  Will report back if the issue returns or not.
> 
> See also threads:
> 
> http://talk.maemo.org/showthread.php?t=42500

That thread seems to point to personal IP address causing the problem.  Anyone
experiencing this *without* that?

(In reply to comment #6)
> That thread seems to point to personal IP address causing the problem.  Anyone
> experiencing this *without* that?
> 

My anectode:
1) I wanted to find my IP address but was too lazy to open the keyboard & start
typing.
2) I added "Personal IP Address" to my desktop, noted my IP, and removed it
immediately. (I'd had it installed for ages but not active).
3) Shortly (15 mins) after, I noticed laggy desktop & hildon-home hogging CPU
for the first time
4) I searched & voted for this bug.

So my experience is consistent with your theory.

Just realised when i enabled touch search widget the issue came back. disabled
the widget and the issue went????

not sure but it could be linked to the issue

Created an attachment (id=2261) [details]
Smaps dump for this issue

I am facing similar problem (not exactly same as described above, tough). After
about 3-4 days since reboot, whenever I resume device from sleep, hildon-home
hogs CPU for about 4-5 seconds without any reason. Memory usage of hildon-home
is about 13-15 per cent, as seen in htop. Tried to restart hildon-desktop, but
didn't help. I also tried swapoff/swapon, not much success either. Attaching
smaps dump, as requested.

Widgets active: conversations inbox, personal dataplan, personal ip address,
media player, fmtx, recaller, touchsearch.

Today in the morning I've been awaken by N900'a alarm clock as usual, however
once I tapped "Stop" button to switch it off, device actually responded after
few seconds and stopped sounding alarm.

Later that morning I've noticed that hildon-home was hammering CPU even longer
than yesterday (up to 10 seconds!) after each device resume, so it basically
started to become unusable for first few seconds since unlocking. I have
actually recorded a video that demonstrates this, but I don't know how to
compress ~170MB .mov file just yet (suggestions welcome directly on my email).

Anyway, I finally just rebooted device and hildon-home behaves now. Each time I
resume device from sleep it takes less than ~10-20% of CPU for less than 1
second, essentially making device usable and responsive straight away.

I reckon there is some kind of memory leak going on here, possibly touching
swap space, so each device resume forces hildon-home to reload data from swap,
however that's just a guess. This issue takes couple of days of uptime before
it gets "visible" for the user (at least for me), so I'll see how things evolve
over next few days.

Once Hildon-home starts to hog memory and CPU resources, the most affected
elements are the incoming message and missed call alerts , clicking them on the
tasks window renders no response. Tapping on other open tasks will open them
even though it would be much slower. Tapping on the message or call alert on
the tasks pane repeatedly causes the 'Hildon-Home not responding' message with
option to terminate the process pops up. Terminating Hildon-home process causes
the system to return to normal state. 

Widgets need to be seperated from the Hildon-Home process so that atleast we
know which widgets are causing the Hildon-home process to hang.

Comment 12 Andre Klapper 2010-02-12 16:10:52 UTC

CC'ing Brent and Andrew (maintainers of Personal IP address and Touchsearch).

So before this bug report gets noisy and mixes up several different things,
let's continue trying to track this down.

According to comment 6, 7, and comment 8, Personal IP address and/or
Touchsearch might cause the problems seen here.

Can EVERYBODY here confirm that this problem goes away by removing these
widgets?
For those who have not done yet, please test and report back.
Thanks.

I am experiencing this problem, but I have not installed Personal IP. 
I do have Touchsearch installed and enabled. My full list of widgets is below - 

Facebook
Dataplan monitor
Touchsearch
Calendar
RSS
OMweather
FM Transmitter

I also get this issue without that widget. Only things I have are:
personal data plan monitor
calendar
conversations inbox widget
command line execution widget
fm transmitter widget

i have not had the issue since removing those widgets. my device is now very
fast and responesive

Since removing personal IP and the other widgets I presented above the phone
has seemed more responsive but I can't completely confirm this as the lack of
responsiveness seems to occur after a few days and I've often had to reboot my
phone after a few days (to change SIMs, etc...).  I will try to see if it stays
responsive but at one point I did notice a slowdown after a few days even
without the widgets.  Unfortunately its hard to quantify the slowdown and be
sure that its happening (there is no process that seems to be eating up an
inordinate amount of memory or cpu time -- phone just becomes sluggish and
irresponsive).

i can also confirm this. opening emails and sms has now become slow from the
multitask window but everything else is fast

I have just started experiencing this issue. hildon-home tops CPU for first
couple of seconds since device wake-up. I've removed Personal IP Monitor and
TouchSearch from desktop first, but haven't noticed any difference. Then I
removed ALL custom widgets, only leaving standard app launcher icons and
contacts, yet still no difference.

What's worth pointing, I guess, removing widgets off the desktop didn't reduce
hildon-home's memory usage, as seen in htop.

(In reply to comment #9)
> Attaching smaps dump, as requested.

Thanks, that shows 33MB allocated in the heap which doesn't identify the
culprit but looks like a good ol' fashioned memory leak.

(In reply to comment #12)
> According to comment 6, 7, and comment 8, Personal IP address and/or
> Touchsearch might cause the problems seen here.
> 
> Can EVERYBODY here confirm that this problem goes away by removing these
> widgets?

Just to confuse things a bit, I have had both of these enabled for a few weeks
now and haven't experienced the problem.

Another common one seems to be simple-fmtx-widget (comments 2, 5, 9, 13 & 14). 
I just had a quick look at its source and to my untrained eye it looks like
it's leaking DBusGProxy objects in its get_set() function.

It's quite possible we have several misbehaving widgets, but for now can anyone
confirm whether disabling that cures the problem for them?

I have the following widgets running:
simple-fmtx-widget
Calendar 

I tried removing all widgets, restarted hildon-home and now things seem ok.
I haven't installed Personal IP address and Touchsearch.

I have removed FMTX and rebooted, will keep an eye out to see if this comes up
again in the next few days

(In reply to comment #19)
> Another common one seems to be simple-fmtx-widget (comments 2, 5, 9, 13 & 14). 
> I just had a quick look at its source and to my untrained eye it looks like
> it's leaking DBusGProxy objects in its get_set() function.
> 
> It's quite possible we have several misbehaving widgets, but for now can anyone
> confirm whether disabling that cures the problem for them?

I was just about to remove fmtx widget and reboot device this morning, however
I have received OTA update of Conversations Inbox widget which apparently has
quietly restarted hildon-home/desktop, as problem went away once that widget
got updated.

Anyway, since it got "fixed" by updating inbox widget, I've just removed fmtx
widget from desktop now and will see what happens over next couple of days.

Today I noticed the device was very slow and not very responsive.
To check what's going on, using 'top' it was showing /usr/bin/calendar using
20%-50$ CPU, not sure what the reason was. I didn't have any applications open
in the background. 

The only thing that I could think of calendar was running is the widget on
Desktop. I closed the widget and the device became fast and responsive again. I
reactivated the calendar widget and /usr/bin/calendar isn't showing using 20%
anymore.

Looking at the changelog 2009.44 against 2009.51 I saw the following addition
in 2009.51:

calendar-ui-widgets-0    0.5-9.16+0m5

From reading the comments in this bug, I think we all have Calendar Widget on
our Home/Desktop and from what I saw during my investigation (/usr/bin/calendar
using 20%-50%) I believe this is the cause of the issue.

If you experienced this issue, try closing calendar widget and reactivate it.

(In reply to comment #23)
> Today I noticed the device was very slow and not very responsive.
> To check what's going on, using 'top' it was showing /usr/bin/calendar using
> 20%-50$ CPU, not sure what the reason was.

I think that's a different issue.  The bug(s) discussed here seem to be
memory-bound (which does cause heavy load when the system goes deep into swap
and starts thrashing) and misbehaving widgets' CPU usage would show up as
hildon-home in top anyway.  Could you file a separate report for it?

I have been experiencing this, as well. I first really noticed it after i
installed the comics widget, but it hasn't completely gone away since
uninstalling that one. I also have:
IP Address
Recaller
Foreca
Calendar
Media Player

On my desktops

im not even running the callender and i have this issue right now.

im ruuning:
data plan monitor
media player
OM weather
simple FM transmitter


the only temp fix i have is to do this in Xterminal

sudo gainroot
killall hildon-desktop

everything is slow. sms's and emails take forever to respone
and shortcuts on the desktop hang for a long time when pressed

(In reply to comment #27)
> im not even running the callender and i have this issue right now.
> 
> im ruuning:
> data plan monitor
> media player
> OM weather
> simple FM transmitter
> 
> 
> the only temp fix i have is to do this in Xterminal
> 
> sudo gainroot
> killall hildon-desktop
> 
> everything is slow. sms's and emails take forever to respone
> and shortcuts on the desktop hang for a long time when pressed
> 



by the way when i removed touch search and IP address it did fix some of the
issues i had for a wwhhillleeee. can narrow down the source thought, but this
is a confirmed issue

(In reply to comment #19)
> Another common one seems to be simple-fmtx-widget (comments 2, 5, 9, 13 & 14). 
> I just had a quick look at its source and to my untrained eye it looks like
> it's leaking DBusGProxy objects in its get_set() function.
> 
> It's quite possible we have several misbehaving widgets, but for now can anyone
> confirm whether disabling that cures the problem for them?

Nope, that's not fmtx. Having it removed for few days (and rebooted device few
times in-between) I have just started experiencing slowness on each resume.

What is interesting tough - it seems this problem starts occurring exactly
around 1.5-2 days of uptime, at least for me. Previously when I've started
experiencing this, I've had ~1d 23h of uptime, now I have 1d 20h...

(In reply to comment #24)
> From reading the comments in this bug, I think we all have Calendar Widget on
> our Home/Desktop and from what I saw during my investigation (/usr/bin/calendar
> using 20%-50%) I believe this is the cause of the issue.
> 
> If you experienced this issue, try closing calendar widget and reactivate it. 

Doesn't seem to solve the issue for me, unfortunately... :(

Comment 30 Eero Tamminen 2010-02-22 18:49:12 UTC

(In reply to comment #18)
> I have just started experiencing this issue. hildon-home tops CPU for first
> couple of seconds since device wake-up. I've removed Personal IP Monitor and
> TouchSearch from desktop first, but haven't noticed any difference. Then I
> removed ALL custom widgets, only leaving standard app launcher icons and
> contacts, yet still no difference.
> 
> What's worth pointing, I guess, removing widgets off the desktop didn't reduce
> hildon-home's memory usage, as seen in htop.

You need also to restart home ("killall hildon-home"") to get rid of the memory
usage.


Btw. If nothing in the top is taking lots of CPU or hugely memory, pleases
check whether "dmesg" output says anything about "SGX".

(In reply to comment #30)
> (In reply to comment #18)
> You need also to restart home ("killall hildon-home"") to get rid of the memory
> usage.

Is there some "nicer" way of relaunching hildon-home (apart from rebooting
device)? When I do this, all 3rd party widgets are gone and I need to re-add
them manually.

> Btw. If nothing in the top is taking lots of CPU or hugely memory, pleases
> check whether "dmesg" output says anything about "SGX".

OK, I'll take a look next time. What SGX is?

same problem different cause:

well the "coming from sleep" issue with 2-5s before the touch responds is one
thing I have too...

the other thing is, when I open the lens cover and close the cam-app its stuck
in this unresponsive state, home menu works, sliding desktops too, but not any
pressed icons on the desktop gets recognized... when I now close the lens cover
- all actions proceed, all programs tried to start via desktop icon pop up
within a few seconds. I dont know if this is related or needs a new bugreport
yet, I get 4/5 hits to reproduce it, another minute it is like 1/5.
just a few minutes ago it was like 5/5, then I passed the device to a friend
who did just the same as I did (open lens cover, closing cam-app, doing
something else) and it did work again with lens cover left open. It seems to
not depend on the program used after closing the cam-app, so if you use the
camera with another program or not seemed to have no impact at all.

widgets on the desktop are:
mediaplayer
calendar
Desktop Command Execution Widget (had it with and without it)
ForecaWeather
Personal Countdown
FM-transmitter (had it with and without it)

Comment 33 Eero Tamminen 2010-02-23 13:17:13 UTC

(In reply to comment #31)
>> You need also to restart home ("killall hildon-home"") to get rid of
>> the memory usage.
> 
> Is there some "nicer" way of relaunching hildon-home (apart from rebooting
> device)? When I do this, all 3rd party widgets are gone and I need to re-add
> them manually.

Reboot does basically this:
$ dsmetool -k /usr/bin/hildon-home
$ dsmetool -t /usr/bin/hildon-home

But at least for me "killall hildon-home" doesn't remove the widgets I've
selected (I don't use any 3rd party ones though, maybe they affect things).


> > Btw. If nothing in the top is taking lots of CPU or hugely memory, pleases
> > check whether "dmesg" output says anything about "SGX".
> 
> OK, I'll take a look next time. What SGX is?

The 3D chip.  There's a non-reproducible issue which some people have bumped
into with SGX doing HW resets which shows up as device slowing down a lot
(hildon-desktop composite manager updates the screen from apps' window buffers
using GLES, so if that HW is busy with something else, screen update slowness
shows up as whole device slowness while this is happening).  Next release is
going to have changes which should help avoiding that, but as long as the issue
is non-reproducible it cannot be fixed completely, or verified to be fixed.

Something spamming system/session D-BUS or dirtying quickly huge amounts of RAM
can show up also as temporary slowdown.  Pre-installed SW doesn't do that (at
least on the background), but 3rd party ones might do.

(In reply to comment #33)
> Reboot does basically this:
> $ dsmetool -k /usr/bin/hildon-home
> $ dsmetool -t /usr/bin/hildon-home
> 
> But at least for me "killall hildon-home" doesn't remove the widgets I've
> selected (I don't use any 3rd party ones though, maybe they affect things).

Yes, only 3rd party widgets are removed ("default" widgets like calendar or
media player remain in place).

> The 3D chip.  There's a non-reproducible issue which some people have bumped
> into with SGX doing HW resets which shows up as device slowing down a lot
> (hildon-desktop composite manager updates the screen from apps' window buffers
> using GLES, so if that HW is busy with something else, screen update slowness
> shows up as whole device slowness while this is happening).  Next release is
> going to have changes which should help avoiding that, but as long as the issue
> is non-reproducible it cannot be fixed completely, or verified to be fixed.

Does that relates with famous "random 32wd_to reboots" issue?

> Something spamming system/session D-BUS or dirtying quickly huge amounts of RAM
> can show up also as temporary slowdown.  Pre-installed SW doesn't do that (at
> least on the background), but 3rd party ones might do.

When I come across hildon-home slowness again, I'll try to disable all 3rd
party desktop widgets I have. I only have few, so I could cope without them for
couple of days, I guess. :)

Comment 35 Eero Tamminen 2010-02-23 17:39:07 UTC

(In reply to comment #34)
> (In reply to comment #33)
> > Reboot does basically this:
> > $ dsmetool -k /usr/bin/hildon-home
> > $ dsmetool -t /usr/bin/hildon-home
> > 
> > But at least for me "killall hildon-home" doesn't remove the widgets I've
> > selected (I don't use any 3rd party ones though, maybe they affect things).
> 
> Yes, only 3rd party widgets are removed ("default" widgets like calendar or
> media player remain in place).

Does using dsmetool like above help?


>> The 3D chip.  There's a non-reproducible issue which some people have bumped
>> into with SGX doing HW resets which shows up as device slowing down a lot
...
> Does that relates with famous "random 32wd_to reboots" issue?

No, the main reason for that was related to power management (not waking up
from HW off-mode to expected state).


>> Something spamming system/session D-BUS or dirtying quickly huge amounts
>> of RAM can show up also as temporary slowdown.  Pre-installed SW doesn't
>> do that (at least on the background), but 3rd party ones might do.
> 
> When I come across hildon-home slowness again, I'll try to disable all 3rd
> party desktop widgets I have. I only have few, so I could cope without them
> for couple of days, I guess. :)

Anything large (say e.g. Python) waking up on the background will also be an
issue.  You can check top (or strace) now and then to see whether something
does stuff on the background (even 1%) although you haven't specifically
requested it to do anything.  If it is, please file a bug.

Closing all browser windows occasionally is also a good idea.  Www-pages &
Flashplayer can cause Browser to use huge amounts of memory & the dynamic
nature of that memory usage can make browser memory very fragmented.  Certain
kind of pages (if I've understood correctly, with images animated from JS) can
still cause it to wake up in the background which causes browser to be swapped
in, and then out when the foreground app wants to do something (this issue is
even worse in upstream Mozilla/Fennec).  We're trying to get that fixed for
next release, but it's possible that fix isn't ready in time for that one.

(In reply to comment #35)
> > > Reboot does basically this:
> > > $ dsmetool -k /usr/bin/hildon-home
> > > $ dsmetool -t /usr/bin/hildon-home
> > > 
> > > But at least for me "killall hildon-home" doesn't remove the widgets I've
> > > selected (I don't use any 3rd party ones though, maybe they affect things).
> > 
> > Yes, only 3rd party widgets are removed ("default" widgets like calendar or
> > media player remain in place).
> 
> Does using dsmetool like above help?

Didn't try. I am waiting until hildon-home starts misbehaving again, and then
I'll try that method. Thanks.

(In reply to comment #36)
> > > > Reboot does basically this:
> > > > $ dsmetool -k /usr/bin/hildon-home
> > > > $ dsmetool -t /usr/bin/hildon-home
> > > > 
> > > > But at least for me "killall hildon-home" doesn't remove the widgets I've
> > > > selected (I don't use any 3rd party ones though, maybe they affect things).
> > > 
> > > Yes, only 3rd party widgets are removed ("default" widgets like calendar or
> > > media player remain in place).
> > 
> > Does using dsmetool like above help?
> 
> Didn't try. I am waiting until hildon-home starts misbehaving again, and then
> I'll try that method. Thanks.
> 

I've got exactly 2 days of uptime passed this morning and guess what -
hildon-home has started misbehaving! I have issued two dsmetool commands as
suggested via ssh session, having conky opened on device screen. When I issued
first command (-k) I've instantly seen significant drop in memory and swap use,
suggesting hildon-home was taking a lot of those. Then I issued a second
command (-t), memory/swap usage bumped a bit again, but not too much.

Desktop widgets remained unaffected after -t command, not for long tough. Just
few seconds later hildon-home crashed and crash-reported popped up (I've sent
the report, are you reading these by any chance, Eero?) and *then* all
3rd-party widgets has disappeared. After another while hildon-home has crashed
again... Another unpleasant side effect was Calendar widget which stopped
displaying any events from calendar, even after I re-added it to the desktop.

All in all, I've rebooted device and now I will only keep default "factory"
widgets on desktop and see what happens with hildon-home in ~2 days time.


Other note: was dsmetool -t /usr/bin/hildon-home command necessary, actually? I
am guessing hildon-home had restarted by itself once I issued -k command first,
hence executing another process started by -t might lead to crash? Am I
thinking right here?

Comment 38 Eero Tamminen 2010-02-24 15:20:54 UTC

(In reply to comment #37)
> I've got exactly 2 days of uptime passed this morning and guess what -
> hildon-home has started misbehaving! I have issued two dsmetool commands
> as suggested via ssh session, having conky opened on device screen. When
> I issued first command (-k) I've instantly seen significant drop in memory
> and swap use, suggesting hildon-home was taking a lot of those. Then
> I issued a second command (-t), memory/swap usage bumped a bit again, but
> not too much.

Ok, so something (applet...) was leaking a lot in the home.


> Desktop widgets remained unaffected after -t command, not for long tough.
> Just few seconds later hildon-home crashed

Did you run the dsmetool commands as normal user or root?
(should be run as normal user, e.g. directly from XTerm)


> and crash-reported popped up (I've sent the report, are you reading
> these by any chance, Eero?)

Only when I'm specifically looking for something.  What are the four last hex
digits in your WLAN MAC (Settings -> About product)?


> and *then* all 3rd-party widgets has disappeared.

I guess Home assumed it crashed because of a 3rd party widget.  It's a
defensive measure to prevent startup/reboot loops.


> After another while hildon-home has crashed again...

dsmetool "-t" option tells DSME SW-watchdog to restart process when it crashes
and if that doesn't help, reboot.  See "dsmetool" for explanation on its
options.


> Another unpleasant side effect was Calendar widget which stopped
> displaying any events from calendar, even after I re-added it to the desktop.
>
> All in all, I've rebooted device and now I will only keep default "factory"
> widgets on desktop

Did the Calendar widget start showing the events again after reboot?


> and see what happens with hildon-home in ~2 days time. 
> 
> Other note: was dsmetool -t /usr/bin/hildon-home command necessary,
> actually?  I am guessing hildon-home had restarted by itself once I
> issued -k command first,

No, -k tells the DSME SW-watchdog to stop the process AND its automatic
restarting.


> hence executing another process started by -t might lead to crash?
> Am I thinking right here?

(In reply to comment #38)
> > Desktop widgets remained unaffected after -t command, not for long tough.
> > Just few seconds later hildon-home crashed
> 
> Did you run the dsmetool commands as normal user or root?
> (should be run as normal user, e.g. directly from XTerm)

As root, unfortunately. I just did the same again as an user, ie. -k followed
by -t after a while. Desktop got back to normal, including 3rd party widget and
calendar widget was showing events properly, plus hildon-home didn't crash.
Lesson learned. :)

> Only when I'm specifically looking for something.  What are the four last hex
> digits in your WLAN MAC (Settings -> About product)?

F3:22

> Did the Calendar widget start showing the events again after reboot?

Yes, thankfully (the most important widget for me :).

> No, -k tells the DSME SW-watchdog to stop the process AND its automatic
> restarting.

Makes sense now. Thanks for explanation.

Story happened again - just below 2 days of uptime and hildon-home misbehaves!
This time I didn't have *any* 3rd party widgets, only stock calendar and media
player widgets. I've restarted hildon-home with dsmetool, as suggested by Eero
and that fixed a problem.

I can see pretty regular pattern developing in my case. It is a 3rd time in a
row when hildon-home starts going bonkers when there's just below 2 days of
uptime (ie. on the day when uptime passes 2nd full day). This makes me thinking
there might sth wrong with calendar widget, namely it could be laking memory
after ~2 days. That's a guess.

For time being I've disabled literally ALL widgets on my desktop and will
report back here in two days time.

Comment 41 Eero Tamminen 2010-02-26 19:07:42 UTC

(In reply to comment #9)
> After
> about 3-4 days since reboot, whenever I resume device from sleep, hildon-home
> hogs CPU for about 4-5 seconds without any reason. Memory usage of hildon-home
> is about 13-15 per cent, as seen in htop. Tried to restart hildon-desktop, but
> didn't help. I also tried swapoff/swapon, not much success either. Attaching
> smaps dump, as requested.

Thanks, I forgot to check this earlier.

You seem to have added some python stuff to Home.  Python is well known for
never releasing memory it has allocated back to the system (it may get back to
C-library, but it's too fragmented so that heap size could be decreased)...

All the relevant memory usage seems to be in heap:
00016000-02067000 rw-p 00016000 00:00 0          [heap]
Size:              33092 kB
Rss:               25416 kB
Pss:               25416 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:       876 kB
Private_Dirty:     24540 kB
Referenced:        22716 kB
Swap:               7612 kB

Over 20MB is a lot of private dirty.  As you say that hildon home spends a lot
of time when you bring it up, I think most of this data is active.  It's not
lost, but actually still (uselessly) used.  It could be Pythons internal
structures or some list that gets new items which widget goes through whenever
it wakes up.


> Widgets active: conversations inbox, personal dataplan, personal ip address,
> media player, fmtx, recaller, touchsearch.

Any idea which of the 3rd party widgets uses Python?


(In reply to comment #39)
> I just did the same again as an user, ie. -k followed by -t after a while.
> Desktop got back to normal, including 3rd party widget and calendar widget

(In reply to comment #40)
> Story happened again - just below 2 days of uptime and hildon-home misbehaves!
> This time I didn't have *any* 3rd party widgets, only stock calendar and media
> player widgets. I've restarted hildon-home with dsmetool, as suggested by Eero
> and that fixed a problem.

Had you restarted home between disabling the above mentioned 3rd party widget
(which one it was?) and the issue you had now?


(In reply to comment #40)
> This makes me thinking there might sth wrong with calendar widget,
> namely it could be laking memory after ~2 days. That's a guess.

If it's the Nokia one that's pre-installed on the device, I think that
unlikely.  I have it enabled and have had device up for weeks at the time
(first month and after forgetting to charge it, now it's been up two weeks).

Or do you have some really huge number of events in the calender? Of some
non-default type?

(In reply to comment #41)
> All the relevant memory usage seems to be in heap:
[...]
> Over 20MB is a lot of private dirty.  As you say that hildon home spends a lot
> of time when you bring it up, I think most of this data is active.  It's not
> lost, but actually still (uselessly) used.  It could be Pythons internal
> structures or some list that gets new items which widget goes through whenever
> it wakes up.

OK, that might be some clue...

> > Widgets active: conversations inbox, personal dataplan, personal ip address,
> > media player, fmtx, recaller, touchsearch.
> 
> Any idea which of the 3rd party widgets uses Python?

Hard to say, really. I *think* but not being sure, that TouchSearch is done
with Python.

> > Story happened again - just below 2 days of uptime and hildon-home misbehaves!
> > This time I didn't have *any* 3rd party widgets, only stock calendar and media
> > player widgets. I've restarted hildon-home with dsmetool, as suggested by Eero
> > and that fixed a problem.
> 
> Had you restarted home between disabling the above mentioned 3rd party widget
> (which one it was?) and the issue you had now?

Basically, I have disabled *all* 3rd party widgets and rebooted device. Having
only calendar and media player widgets, I got that issue with hildon-home
again.

I have now removed literally all widgets altogether from the desktop, leaving
only app icons, bookmarks and contacts, and rebooted device. Once I pass two
full days of uptime, I'll report back with my observations.

> (In reply to comment #40)
> > This makes me thinking there might sth wrong with calendar widget,
> > namely it could be laking memory after ~2 days. That's a guess.
> 
> If it's the Nokia one that's pre-installed on the device, I think that
> unlikely.  I have it enabled and have had device up for weeks at the time
> (first month and after forgetting to charge it, now it's been up two weeks).
> 
> Or do you have some really huge number of events in the calender? Of some
> non-default type?

Hmm, depends what do you mean by "huge" and "non-default" type. At this very
moment, I have total of 28 events in main calendar (usually it's below 20 but I
am going to have busy weekend :), and 54 events in birthday calendar. I have
couple of recurring events too, if that matters. In fact, I use calendar a lot
and often synchronize it with Google Calendar via SyncML using SyncEvolution,
so events are coming in/out on daily basis. I don't use Mail for Exchange at
all since it stopped working with Google Sync service.

Reason I've started suspecting calendar is a reason for hildon-home troubles is
that timing consistency when problem occurs. As I said earlier - for a third
time in a row I've started experiencing slowness at the moment when device was
just before second full day of uptime (ie. about 1d20h onwards).

Comment 43 Eero Tamminen 2010-03-01 10:50:16 UTC

(In reply to comment #42)
> Hmm, depends what do you mean by "huge" and "non-default" type. At this
> very moment, I have total of 28 events in main calendar (usually it's below
> 20 but I am going to have busy weekend :), and 54 events in birthday
> calendar. I have couple of recurring events too, if that matters.
> In fact, I use calendar a lot and often synchronize it with Google Calendar
> via SyncML using SyncEvolution, so events are coming in/out on daily basis.

Ok, I'm not using syncing and have only my nieces' birthdays in the calender,
so your usage pattern is quite different from mine.  One possible issue might
be syncing, especially if that changes (adds/removes) items visible in the
calendar widget, I'm not sure how throughly that's tested from the resource
consumption point of view (e.g. for birthday events).


> I have now removed literally all widgets altogether from the desktop, leaving
> only app icons, bookmarks and contacts, and rebooted device. Once I pass two
> full days of uptime, I'll report back with my observations.

Thanks, I'm very interested to hear the results!

Unfortunately, I have now passed two full days of uptime without *any* desktop
widget and I experience hildon-home trouble again. :(

This time I was looking into this more closely and witnessed how hildon-home
gradually but relatively quickly has been eating more and more CPU resources
after each wakeup. When device was roughly at 1d16h uptime, h-h was taking up
to ~20-30% of CPU for very short (yet noticeable) while after wakeup. After
another 2-3 hours it was more noticeable, with over 50% of CPU being eaten.
Another couple of hours (essentially yesterday evening), h-h was hitting 100%
CPU... and so on and on. Today in the morning, while 2d10h uptime, it started
affecting general device use, ie. when alarm clock went off in the morning, it
took about 1-2 extra seconds to respond to "Stop" button on the screen. :(

I haven't done anything particularly unusual over past two days, at least I
can't think of anything that could affect h-h in such way. I also did have a
look into dmesg for SGX ocurrences (dmesg | grep -i sgx) but did't find
anything either. I haven't restarted h-h yet and at this very moment I have
~171MB used RAM, ~155MB used swap and hildon-home takes 70504 VIRT, 23668 RES
and 5256 SHR as I read columns from htop. If there's anything else that I can
do to trace this issue down, please let me know.


PS. I have realised I have another 'widget' installed, which is "Custom
Operator Name Widget". It's not usual widget as the others that you could add
to the desktop from menu and all it does is replacing standard mobilr operator
name on top of the screen, so not sure if that could be the reason for h-h
misbehaving really...

(In reply to comment #33)
> Ok, I'm not using syncing and have only my nieces' birthdays in the calender,
> so your usage pattern is quite different from mine.  One possible issue might
> be syncing, especially if that changes (adds/removes) items visible in the
> calendar widget, I'm not sure how throughly that's tested from the resource
> consumption point of view (e.g. for birthday events).

Even with no calendar widget on desktop, I get this issue. However I'm
suspecting frequent changes in calendar itself, even without widget, could
affect hildon-home somehow. But that's just a guess...

Comment 46 Eero Tamminen 2010-03-01 11:28:53 UTC

(In reply to comment #44)
> This time I was looking into this more closely and witnessed how hildon-home
> gradually but relatively quickly has been eating more and more CPU resources
> after each wakeup. When device was roughly at 1d16h uptime, h-h was taking up
> to ~20-30% of CPU for very short (yet noticeable) while after wakeup. After
> another 2-3 hours it was more noticeable, with over 50% of CPU being eaten.

Does it use CPU also when it's on background?

If yes, could you strace it and report what it does?

If the CPU usage is only when topping Home, could you strace what it does at
that point (start strace before topping)?  This may get a lot of data.

If that doesn't show anything interesting, ltrace might (but ltrace has some
issues, so I would use strace first).


> PS. I have realised I have another 'widget' installed, which is "Custom
> Operator Name Widget". It's not usual widget as the others that you could add
> to the desktop from menu and all it does is replacing standard mobilr operator
> name on top of the screen, so not sure if that could be the reason for h-h
> misbehaving really...

I don't have that kind of an issue with several pre-installed widgets enabled,
so any kind of differences in the setups are suspicious...


(In reply to comment #45)
> Even with no calendar widget on desktop, I get this issue. However I'm
> suspecting frequent changes in calendar itself, even without widget, could
> affect hildon-home somehow. But that's just a guess...

Only calendar should be interested about calendar events.  But if you're
synching also contacts, there are more things that are interested about changes
for those.

(In reply to comment #46)
> Does it use CPU also when it's on background?

No, it only tops CPU for the first few seconds after waking up device (ie.
unlocking with slide key) - before and then it doesn't do any harm. CPU topping
extends in time along with uptime, ie. yesterday (~1.5 days of uptime) it was
topping CPU for about 1-3 secs. Few minutes ago I did test (over 2.5 days
uptime) and it topped CPU with near-100% use for 7 seconds after wakeup. Once
it's done, it works pretty much OK until the next sleep/wakeup cycle.

> If yes, could you strace it and report what it does?
> 
> If the CPU usage is only when topping Home, could you strace what it does at
> that point (start strace before topping)?  This may get a lot of data.
> 
> If that doesn't show anything interesting, ltrace might (but ltrace has some
> issues, so I would use strace first).

I've installed strace, exectued "strace -o strace.log /usr/bin/hildon-home" via
SSH session and unlocked device. After about 10 seconds, once hildon-home
stopped hammering CPU, I've done ctrl-c on strace. Attaching strace.log.

> I don't have that kind of an issue with several pre-installed widgets enabled,
> so any kind of differences in the setups are suspicious...

I will uninstall Custom Operator Name Widget then. The trouble is that I'd need
to wait another 1-2 days until I can see any difference. This issue isn't
reproducible straight away or at least I don't know how to reproduce it
otherwise.

> Only calendar should be interested about calendar events.  But if you're
> synching also contacts, there are more things that are interested about changes
> for those.

I don't sync contacts, just calendar.

Btw, shall we change this entry description to sth like "hildon-home tops CPU
after unlocking device while >1 days of uptime"?

Created an attachment (id=2381) [details]
Strace output while unlocking device

Exectued "strace -o strace.log /usr/bin/hildon-home" via
SSH session and unlocked device. After about 10 seconds, once hildon-home
stopped hammering CPU, I've done ctrl-c on strace.

Interesting thing... I've just noticed that Custom Operator Name Widget has
disappeared from desktop, probably after doing strace. :-o It's still there in
Settings menu, but I can't bring it back to desktop - unless I reboot device of
restart hildon-home, but I'd like to avoid that for now.

David - there's not much detail in the strace. Did you start it with:
strace -f -p <PID>

the -f is necessary to trace individual threads
the -p <PID> is necessary to attach to the existing hildon-home (it looks as
though you started a new instance of hildon-home rather than attach to the
existing one)

Created an attachment (id=2382) [details]
Strace output while unlocking device (second try)

I've had to hildon-home processes running:

root@n900:~# ps aux | grep hildon-home
 1108 user      3936 S    /usr/bin/hildon-home 
 1113 user     75488 S    /usr/bin/hildon-home

However I found that 1113 was doing harm after unlock, so I attach the output
of following command:

strace -t -p 1113 -o strace2.log

Followed by unlocking device, as previously, in order to make hildon-home
hammer CPU.

Hope this helps.

(In reply to comment #50)
> (it looks as
> though you started a new instance of hildon-home rather than attach to the
> existing one)
> 

That would also explain disappearance of Custom Operator Name Widget, which
I've noted in comment #49.

(In reply to comment #50)
> David - there's not much detail in the strace. Did you start it with:
> strace -f -p <PID>

Is there anything useful in additional strace I have created? Should I do more
tests? Please let me know, as I've just nearly missed a call due to
hildon-home, as it apparently blocked phone UI from appearing straight away
when call came in, so I am now tempted to restart h-h or reboot device just to
get rid if this issue - but then I'd have to wait another couple of days for
issue to come back for further tests...

Thanks in advance.

I am now at +3days uptime and have not any problem of yours, the camera slide
being open to hold back program-execution is wierd but not a problem I can
reproduce that often, I now have a device here with longer uptime than this bug
shows and those modifications

3.2010.02-8
Theme: 
Matrix 1.1

Widgets:
Calendar Widget PR1.1
Mediaplayer Widget PR1.1
Simple FMTX desktop Widget 0.3.0
3x Desktop Command Execution Widget 0.9
Countdown Home Desktop Widget 0.6-1
Custom Operator Name Widget 0.1

Applets:
Load Applet 0.4.6-5
Simple Brightness Applet 1.1-1maemo0
3G2GDual Mode Selection Applet 0.4-2

If you want me to run some tests just shoot them!
If you have less or the same stuff running as I do but one or two you might
check back after disabling "one" of those.

Dawid,

your strace shows a whole load of gettimeofday calls lasting ~6 seconds,
preceded by writing something to a socket (DBUS?) including the text
"apps/connui-cellular/operat...". Suspicion falls on Custom Operator Name
widget...?

I had a few dozen gettimeofday calls for the same strace (nothing like the
amount you had, but I'm not experiencing the same delays).

Removing the Custom Operator Name widget has removed the suspect strace
activity completely.

If you want to reboot (I wouldn't blame you!), try removing that widget & see
if it fixes the problem. I know it'll be a couple of days!

(In reply to comment #55)
> Dawid,
> 
> your strace shows a whole load of gettimeofday calls lasting ~6 seconds,
> preceded by writing something to a socket (DBUS?) including the text
> "apps/connui-cellular/operat...". Suspicion falls on Custom Operator Name
> widget...?
> 
> I had a few dozen gettimeofday calls for the same strace (nothing like the
> amount you had, but I'm not experiencing the same delays).
> 
> Removing the Custom Operator Name widget has removed the suspect strace
> activity completely.
> 
> If you want to reboot (I wouldn't blame you!), try removing that widget & see
> if it fixes the problem. I know it'll be a couple of days!

OK, did that. Removed Custom Operator Name Widget and rebooted device. I also
generated couple of additional strace logs - before and after boot. Will attach
them in a minute.

Created an attachment (id=2389) [details]
Strace output before reboot

Strace output *with* Custom Operator Name Widget and *before* reboot

Created an attachment (id=2390) [details]
Strace output after reboot

Strace with Custom Operator Name Widget removed and *after* reboot

(In reply to comment #54)
> I am now at +3days uptime and have not any problem of yours, the camera slide
> being open to hold back program-execution is wierd but not a problem I can
> reproduce that often, I now have a device here with longer uptime than this bug
> shows and those modifications
> 
> 3.2010.02-8
> Theme: 
> Matrix 1.1
> 
> Widgets:
> Calendar Widget PR1.1
> Mediaplayer Widget PR1.1
> Simple FMTX desktop Widget 0.3.0
> 3x Desktop Command Execution Widget 0.9
> Countdown Home Desktop Widget 0.6-1
> Custom Operator Name Widget 0.1
> 
> Applets:
> Load Applet 0.4.6-5
> Simple Brightness Applet 1.1-1maemo0
> 3G2GDual Mode Selection Applet 0.4-2
> 
> If you want me to run some tests just shoot them!
> If you have less or the same stuff running as I do but one or two you might
> check back after disabling "one" of those.

You seem to have quite similar desktop setup to mine, main difference is that
I'm still running PR1.1, while you're on PR1.1.1...

And you have Custom Operator Name Widget too. :-o Doh!

maybe this is what we were looking for?!

I recognized that some have OMweather installed so did I... mmh nice GPS based
weather info... seems to be wrong location, lets see what location-test-gui
does without A and network, mmh nice fix in <30seconds 5/6 sats used, back to
omweather... not responding, desktop edit mode, config-button not responding,
can swipe to right desktop but not to left weird...
removed OM, still cant swipe to the left on the desktop where OM used to be, OM
also played up with doing weird things with resizing the space it needs putting
the X (desktop-edit-mode)in top right corner while in single day view located
bottom left...

strace is repeating some like this...
http://debian.pastebin.com/8907LyJW

just for the records: 3days 23:20 uptime with no problems until I installed
OMweather, which already played up the first second I set it up, and started
location-test-gui to get a quick location fix to test the GPS based weather
info feature (was showing hagenaeu for some reason).

dsmetool -k did the job to come back alive in normal state after about 1
minute.

Comment 62 Eero Tamminen 2010-03-02 12:56:13 UTC

(In reply to comment #51)
> Created an attachment (id=2382) [details] [details]
> Strace output while unlocking device (second try)
> 
> I've had to hildon-home processes running:
> 
> root@n900:~# ps aux | grep hildon-home
>  1108 user      3936 S    /usr/bin/hildon-home 

This smaller one is the maemo-invoker.  See:
  ls -l /usr/bin/hildon-home

>  1113 user     75488 S    /usr/bin/hildon-home

This is the actual application (maemo-launcher instance that loaded
hildon-home.launch file and set its name as hildon-home).


> However I found that 1113 was doing harm after unlock, so I attach the output
> of following command:
> 
> strace -t -p 1113 -o strace2.log
> 
> Followed by unlocking device, as previously, in order to make hildon-home
> hammer CPU.

Thanks!  I've never seen any process do this many gettimeofday calls (over
three thousand within couple of secs) without any other syscalls in between. 
Something running in Home must be doing something very stupid.

Gettimeofday is one of the fastest syscalls, the device is able to more of them
than here, so the process is also doing something else (which the large active
amount of memory was also indicating).


Btw.  In the discussion thread linked from first comment, the touch search
widget (which uses Python?) was mentioned as causing the issue and the AP news,
load applet[1] and IP thingly were also mentioned.  It's possible that several
of the 3rd party widgets have at least memory usage issues...

(Volunteer testers for Extras are unlikely to check how things behave during
several days and take endurance snapshots to see leakage like is done for the
pre-installed SW.  I added some notes about the tools one can use for that to
http://wiki.maemo.org/Bugs:Stock_answers#Memory_issues)


[1] Ive noticed huge memory leakage mentioned in a bug for Load applet in
relation to screen recording.  It's supposed to be now fixed, but I'm not sure
whether somebody's tested it for over several days (that leakage was within
minutes).


(In reply to comment #60)
> removed OM, still cant swipe to the left on the desktop where OM used to be,
> OM also played up with doing weird things with resizing the space it needs
> putting the X (desktop-edit-mode)in top right corner while in single day
> view located bottom left...
> 
> strace is repeating some like this...
> http://debian.pastebin.com/8907LyJW

For screen updates it's better to use e.g. "xresponse".  Screen updates produce
way too much data for strace.

(In reply to comment #62)
> Btw.  In the discussion thread linked from first comment, the touch search
> widget (which uses Python?) was mentioned as causing the issue and the AP news,
> load applet[1] and IP thingly were also mentioned.  It's possible that several
> of the 3rd party widgets have at least memory usage issues...
[...]
> [1] Ive noticed huge memory leakage mentioned in a bug for Load applet in
> relation to screen recording.  It's supposed to be now fixed, but I'm not sure
> whether somebody's tested it for over several days (that leakage was within
> minutes).

Speaking of load-applet. It happens that I have that applet installed too
(although it's "ligher" version, the one without screenshot/screencast
features). Does hildon-home also handle status bar applets? I thought it's only
handling *desktop* widgets, while status bar is attached to different process,
separate from hildon-home.

Comment 64 Eero Tamminen 2010-03-03 18:57:56 UTC

(In reply to comment #63)
> Does hildon-home also handle status bar applets?
> I thought it's only handling *desktop* widgets, while status bar is
> attached to different process, separate from hildon-home.

Correct.  It's just that something (especially if it's not on background and
throttled by cgroups), can harm also performance of rest of the system by
making it swap.  Statusbar is visible unless app is fullscreen, so I don't
think cgroups to throttle it.

Hm. This can actually be one of the reasons which makes the memory leakage most
visible when switching to home.  Cgroups throttles backgrounded applications
(AFAIK including home) when they go to background so that foreground
application has enough memory.  This means that if one switches applications
when the system is low on memory, and especially if the new application has
large _active_ set of memory, a lot of memory needs to be swapped in (and
previous foreground application swapped out when cgroups throttles it).

It would be good if you can take endurance snapshots about the device state at
regular intervals while this issue gets worse, and then attach the processed
endurance data report:
http://wiki.maemo.org/Documentation/devtools/maemo5/sp-endurance
http://wiki.maemo.org/Documentation/devtools/maemo5/sp-endurance-postproc

(You can ignore the doc section about "Emphasizing leakage", just call the save
script, as root, at regular intervals.  It's easiest to get the data out of the
device if you give something under MyDocs as the target directory for the
data.)

(In reply to comment #64)
> It would be good if you can take endurance snapshots about the device state at
> regular intervals while this issue gets worse, and then attach the processed
> endurance data report:
> http://wiki.maemo.org/Documentation/devtools/maemo5/sp-endurance
> http://wiki.maemo.org/Documentation/devtools/maemo5/sp-endurance-postproc

Thanks, Eero. I will try to do that, however I am off abroad until 20th of
March with limited online access and time to do extensive tests. I also might
frequently swap SIM cards in my N900 which obviously won't help to reproduce
this issue.

Anyway, I have noted your suggestion and will try to do endurance tests
sometime soon, reporting results here.

Quick update - I now have 2d4h of uptime and no problem whatsoever with
hildon-home. I have all widgets back on desktop, including 3rd party widgets
like TouchSearch or Personal IP/Dataplan Monitor. I only removed that Custom
Operator Name Widget.

The other difference is that I am abroad now and my N900 hosts different SIM
card than before. Probably that doesn't matter, but I thought it's worth
noting.

(In reply to comment #66)
> Quick update - I now have 2d4h of uptime and no problem whatsoever with
> hildon-home. I have all widgets back on desktop, including 3rd party widgets
> like TouchSearch or Personal IP/Dataplan Monitor. I only removed that Custom
> Operator Name Widget.

I suspect that there's something going on with Custom Operator Name Widget. I
also suspect that it's related to the number of times your display switches on
& off. That is, the pause gets slightly longer each time. Dawid, do you lock &
unlock very frequently, or have a very short backlight timeout? That might
explain why your problem is worse that anyone else's (for example Rüdiger or
me, who also have the widget installed).

I've emailed Faheem Pervez (author of Custom Operator Name Widget) & asked him
if there might be anything going on here. I couldn't see anything wrong in the
source code myself. He's a busy guy but was helpful & is going to take a look
to see if he can find anything.

(In reply to comment #67)
> I suspect that there's something going on with Custom Operator Name Widget.
I don't have it installed (never had) and still experience this issue.

(In reply to comment #68)
> (In reply to comment #67)
> > I suspect that there's something going on with Custom Operator Name Widget.
> I don't have it installed (never had) and still experience this issue.
> 

Could you do an strace of hildon-home waking up (in the same way that Dawid
did) so that we can determine whether the cause is the same?

(In reply to comment #67)
> I suspect that there's something going on with Custom Operator Name Widget. I
> also suspect that it's related to the number of times your display switches on
> & off. That is, the pause gets slightly longer each time. Dawid, do you lock &
> unlock very frequently, or have a very short backlight timeout? That might
> explain why your problem is worse that anyone else's (for example Rüdiger or
> me, who also have the widget installed).

Depends what should we mean by "frequently". I suppose I do lock/unlock it
quite frequently, as I'm using my N900 as default phone. However over past two
days, I haven't used it too much, to be honest, so maybe that's why hildon-home
seems to behave quite well.

Anyway, I am looking into this issue as much as I can and will surely report
any interesting observations. Your advice and help here is much appreciated!

(In reply to comment #68)
> (In reply to comment #67)
> > I suspect that there's something going on with Custom Operator Name Widget.
> I don't have it installed (never had) and still experience this issue.
> 

Same here.  I've never installed Customer Operator Name Widget, and I still
experience this issue.

Comment 72 Eero Tamminen 2010-03-05 09:57:57 UTC

(In reply to comment #71)
>>> I suspect that there's something going on with Custom Operator Name Widget.
>> I don't have it installed (never had) and still experience this issue.
> 
> Same here.  I've never installed Customer Operator Name Widget, and I still
> experience this issue.

See comment 62, there are apparently several 3rd party widgets with long term
memory usage issues.

Uptime 7d 19h 19"

it looks like the time the touchscreen is unresponsive after opening or waking
up the device is getting longer over time but that could be just my
impression?!

no further hangups after the one with OM

Still, same setup and I only got this problem with installing OMweather or
using the camera without using the shipped programme

3.2010.02-8
Theme: 
Matrix 1.1

Widgets:
Calendar Widget PR1.1.1
Mediaplayer Widget PR1.1.1
Simple FMTX desktop Widget 0.3.0
3x Desktop Command Execution Widget 0.9
Countdown Home Desktop Widget 0.6-1
Custom Operator Name Widget 0.1

Applets:
Load Applet 0.4.6-5
Simple Brightness Applet 1.1-1maemo0
3G2GDual Mode Selection Applet 0.4-2

btw I use it as my primary device, daily action (calendar, phone, IM, browser,
widgets, ...)

I'm also having this issue quite often (Once a day?). Although the screen is
responsive, none of the shorcuts will react. 

I'm in the latest firmware and my usual widgets are:
Calendar, Conversations, Desktop command Execution, Media Player, Tunewiki,
Simplenote, Personal photo frame, systeminfo and touchsearch. Additionally I
have a bunch of shortcuts.

I have this problem very severely on my n900, to the point that no hildon
desktop apps work anymore.

Running top after a reboot shows that calendar takes up ~60% cpu / mem. Killing
it does not help the problem however. After killing it, hildon-home takes up
40-60% cpu / mem.

I have flashed the eMMC on my phone and tried applying the latest firmware
update to the phone via OTAs from
RX-51_2009SE_1.2009.42-11.203.2_PR_COMBINED_203_ARM and flashing to the latest
firmware directly. I have also removed ALL apps from hildon app manager. I
can't remove desktop widgets as doing so causes hildon-home to become
unresponsive and to restart.

I will be returning my phone to Nokia within a couple of days, please let me
know if there is any valuable information I can get for anyone and how to get
it if I can help in the meantime.

Cheers

I resolved my problem with desktop hanging by setting my system date to
01/01/2009, removing the calendar widget and then setting it back.

What caused me to do this was I noticed in top the widget was a hog but could
not remove it from the desktop. When I flashed my phone I lazily did not reset
the system time and found the calendar widget to be working, so took the
oppurtunity to remove it and reset the time to present.

Can someone else see if this helps? I have a suspicion that there's a problem
with the latest release of the calendar app.

Cheers

Comment 77 Eero Tamminen 2010-03-08 17:39:28 UTC

(In reply to comment #75)
> I can't remove desktop widgets as doing so causes hildon-home to become
> unresponsive and to restart.

The desktop widgets aren't removed when hildon-home restarts?

If not, what if you do this from XTerm:

- terminate hildon-home:
  dsmetool -k /usr/bin/hildon-home

- start it directly:
  hildon-home

- try removing the widgets

Does hildon-home report anything?


(To get hildon-home run again with the SW watchdog, give it Ctrl-C in XTerm and
then run:
/etc/X11/Xsession.post/18hildon-home
)

> If not, what if you do this from XTerm:
> 
> - terminate hildon-home:
>   dsmetool -k /usr/bin/hildon-home
> 
> - start it directly:
>   hildon-home
> 
> - try removing the widgets
> 
> Does hildon-home report anything?
> 

I have 3.2010.02-8 version of FW
Widgets:
- Calendar
- conversations inbox

I´m sorry but those commands do not work for me as normal user in xterm. I have
to use it with full path:
/usr/sbin/dsmetool -k /usr/bin/hildon-home
to terminate and to restart:
/usr/sbin/dsmetool -t /usr/bin/hildon-home
(If I remember correctly as root dsmetool works everywhere)

After temporary slowdown of hildondesktop I killed hildon-home process and
started it from terminal to see if it reports anything. Only thing I got was
after ctrl-c:
"^Cprocess 10003: arguments to dbus_connection_unregister_object_path() were
incorrect, assertion "path != NULL" failed in file dbus-connection.c line 5567.
This is normally a bug in some application using D-Bus library."
Maybe just something to do killing process by ctrl-c?

btw. I have little hard time to understand that WHEN should I use endurance or
other debugging scripts? Slowdown might happen after couple of days, but when
it happens should I just try to start xterm and run commands or should I
constantly run something?

long story short:
unresponsiveness after unlock is related to hildon-home playing up with 98% C0
for about 3 seconds. also sound alert for incoming msgs was scrambled. dsme..
-k .../hildon-home does fix this and as long as you do not put 3rd party
widgets on your desktop the responsiveness stays 100% and sounds not scrambled
anymore.

Now I recognized the applets (not currently showing on desktop) run in
background or at least one did (foreca) for the others I didnt check, but
adding the missing widgets again, brings them back to the last position if I am
on the desktop they belonged to.

strace shows about 50 gettimeofday/second every 15 seconds but nothing special
else.

right after the setup of adding the widgets back on desktop I received an IMmsg
and the sound was scrambled again. Responsiveness right after unlock is between
90 and 95%

issues occur about every 48h (not sure can be more or less 44h or 52h)

root@cassiopeia:~# uptime
 12:39:47 up 12 days, 19:28, load average: 0.13, 0.24, 0.38

Comment 80 Eero Tamminen 2010-03-10 19:04:35 UTC

(In reply to comment #78)
> I´m sorry but those commands do not work for me as normal user in xterm. I
> have to use it with full path:
> /usr/sbin/dsmetool -k /usr/bin/hildon-home

Right, sorry.  (I had just done "su user" from root console and dsmetool is in
root's $PATH)


> btw. I have little hard time to understand that WHEN should I use endurance or
> other debugging scripts?

sp-endurance should be used if you:
- want to track all device resources (which is usually good idea) _changes_
- don't mind each snapshot taking several MB / snapshot and the data needing
  post-processing
- don't need to run it very frequently (e.g. at few second intervals)

If you want to see overview of system or specific processes memory & CPU usage
changes within short time periods (e.g. at 1 sec interval), use mem-cpu-monitor
from sp-memusage package.

If you just want to see how much memory some process uses (instead of usage
_changes_), use the trivial mem-smaps-private script from the same sp-memusage
package.


> Slowdown might happen after couple of days, but when it happens should
> I just try to start xterm and run commands or should I constantly run 
> something?

In your case, when first noticing the issue, I would use "top" to see what is
the issue, CPU or memory, then use mem-smaps-private to get more accurate
values on their memory usage (private/dirty + swap) and once I had identified
some suspicious processes, I would start taking endurance snapshots at some
suitable interval (in your case, maybe at few hour intervals) to see whether it
leaks, and does it leak also something else than memory.

(In reply to comment #74)
> I'm also having this issue quite often (Once a day?). Although the screen is
> responsive, none of the shorcuts will react. 
> I'm in the latest firmware and my usual widgets are:
> Calendar, Conversations, Desktop command Execution, Media Player, Tunewiki,
> Simplenote, Personal photo frame, systeminfo and touchsearch. Additionally I
> have a bunch of shortcuts.

I have been using the dsmetool -k and -t to get it working again, but this bug
is really pissing me off. I've noticed it ussually happens after a missed call
(Or something related to phone).

I have also noticed that my CPU is not neccesarily busy when hildon home
becomes unresponsive. Before killing the process I check with top and CPU is
below 10%. 

In talk.maemo.org somebody pointed out the following: 
"I think it may be related to processes that haven't exited smoothly, and are
still hanging around in a partially exited state."

What do you guys think?

Comment 82 Eero Tamminen 2010-03-18 19:31:33 UTC

(In reply to comment #81)
> (In reply to comment #74)
>> I'm also having this issue quite often (Once a day?).
>> Although the screen is responsive, none of the shorcuts will react. 

What actually is responsive?

(Home view panning is done by Desktop, not Home.)


>> I'm in the latest firmware and my usual widgets are:
>> Calendar, Conversations, Desktop command Execution, Media Player, Tunewiki,
>> Simplenote, Personal photo frame, systeminfo and touchsearch. Additionally I
>> have a bunch of shortcuts.

In general it's a bad idea to use Python in an always running process like
Statusbar or Home.  I think at least touchsearch uses python (after removing
applets, you need to restart Home to get rid of their memory usage in Home
too).


> I have been using the dsmetool -k and -t to get it working again, but this bug
> is really pissing me off. I've noticed it ussually happens after a missed call
> (Or something related to phone).

Policy daemon will freeze other applications (AFAIK including Home) for a
second or two when you get an incoming call.  This is needed to get call in
time when device is e.g. heavily swapping.

This will also imply that they will get swapped out so that call UI can come
in.  If stuff in Home uses huge amount of RAM and gets swapped out, it will be
somewhat non-responsive while it gets swapped in again.


> I have also noticed that my CPU is not neccesarily busy when hildon home
> becomes unresponsive.

Maybe some 3rd party applet you have doesn't like Home being stopped for a
while?


> Before killing the process I check with top and CPU is below 10%. 

What about IO percentage?  (i.e. is there a lot of swapping going on)


> In talk.maemo.org somebody pointed out the following: 
> "I think it may be related to processes that haven't exited smoothly, and are
> still hanging around in a partially exited state."
> 
> What do you guys think?

If that means so called "Zombie" state, those kind of processes shouldn't be a
problem (unless "ps" shows you having something like thousands of them in Z
state). Zombie processes don't use CPU as they've already exited, kernel just
keeps a little data about them until their parent process "collects" them.

(In reply to comment #82)
> What actually is responsive?
> (Home view panning is done by Desktop, not Home.)

I can move between desktops, I can use the menu, I can click my favorite
contacts and call them and I can use the simplenotewidget. Rest of shortcuts
and widgets are there, but not working (For example, the desktop execution
widget will not update anymore). Everytime I press over them, is like pressing
in the desktop, in the sense that I hear the click-sound and I see the desktop
configuration coming down (I can't remember if I can enter the configuration
and make changes, but I think I tried once and didn't work). I can receive
calls, but the yellow notifications never show when missed calls or messages
are pending (In fact I don't think messages come at all).

> In general it's a bad idea to use Python in an always running process like
> Statusbar or Home.  I think at least touchsearch uses python (after removing
> applets, you need to restart Home to get rid of their memory usage in Home
> too).

I unistalled touchsearch a while ago, but the bug keeps coming (I haven't added
anything new since then). I don't know if any of the other widgets use python. 

> Policy daemon will freeze other applications (AFAIK including Home) for a
> second or two when you get an incoming call.  This is needed to get call in
> time when device is e.g. heavily swapping.
> This will also imply that they will get swapped out so that call UI can come
> in.  If stuff in Home uses huge amount of RAM and gets swapped out, it will be
> somewhat non-responsive while it gets swapped in again.

Sometimes I only realize it is frozen after a while, so it had enough time to
swap again.

> Maybe some 3rd party applet you have doesn't like Home being stopped for a
> while?

Sounds like an option, but how can I identify it? And why it only happens every
now and then? The chance of having the bug also increases with uptime.


> What about IO percentage?  (i.e. is there a lot of swapping going on)

I don't know how to check it. Is it the upper two lines in top? I haven't check
there, but if I'll do it next time.

> If that means so called "Zombie" state, those kind of processes shouldn't be a
> problem (unless "ps" shows you having something like thousands of them in Z
> state). Zombie processes don't use CPU as they've already exited, kernel just
> keeps a little data about them until their parent process "collects" them.

How can I know how many processes I have in that state?

Thanks for your help!!!

Comment 84 Eero Tamminen 2010-03-19 10:27:02 UTC

(In reply to comment #83)
> I can move between desktops, I can use the menu, I can click my favorite
> contacts and call them and I can use the simplenotewidget. Rest of shortcuts
> and widgets are there, but not working (For example, the desktop execution
> widget will not update anymore).

Ok, so Home in general is working, but certain parts of it aren't.


>> Maybe some 3rd party applet you have doesn't like Home being stopped
>> for a while?
> 
> Sounds like an option, but how can I identify it?

One possibility is to install syslog (make sure you have enough space (several
tens of MB) on root file system and remove it and /var/log/syslog* log files
once you don't need it so that it won't fill your root fs).

When the issue happens again, check whether there were any error messages from
home:
  grep hildon-home /var/log/syslog|tail -20

(You need to be root to be able to access syslog files.)


> And why it only happens every now and then?

It can be a race-condition.

> The chance of having the bug also increases with uptime.

And home getting slower could increases the probability.


> > What about IO percentage?  (i.e. is there a lot of swapping going on)
> 
> I don't know how to check it. Is it the upper two lines in top?
> I haven't check there, but if I'll do it next time.

It's the value before "io" in "top".


>> If that means so called "Zombie" state,...

> How can I know how many processes I have in that state?

The "STAT" column in "ps" output contains "Z".  But that's unlikely reason. "D"
state is more interesting (usually happens when processes are blocked due to
slow disk access, swapping etc).

(In reply to comment #84)
> (In reply to comment #83)
> > > What about IO percentage?  (i.e. is there a lot of swapping going on)
> > 
> > I don't know how to check it. Is it the upper two lines in top?
> > I haven't check there, but if I'll do it next time.
> 
> It's the value before "io" in "top".

Sorry for spam, but ain't that "idle" percentage? "IO" percentage is AFTER it
in the top application.

(In reply to comment #83)
> (In reply to comment #82)
> > What actually is responsive?
> > (Home view panning is done by Desktop, not Home.)
> 
> I can move between desktops, I can use the menu, I can click my favorite
> contacts and call them and I can use the simplenotewidget. Rest of shortcuts
> and widgets are there, but not working [...]

I came across this one too. I've had about 5 days of uptime, no problem with
hildon-home topping CPU after resume but suddenly some parts of desktop became
unresponsive. I don't remember exactly, but I think dsmetool -k -t fixed this
issue (it happened few days ago).

Apart from that, I've been using my N900 as default mobile phone in Poland over
past 2 weeks and I haven't noticed problem with "misbehaving" hildon-home even
once, despite running more than 2-3 days of uptime. I am coming back to the UK
tomorrow, will put my UK SIM card back into N900 and will see whether problem
comes back.

Comment 87 Eero Tamminen 2010-03-19 15:32:47 UTC

(In reply to comment #85)
> > It's the value before "io" in "top".
> 
> Sorry for spam, but ain't that "idle" percentage?
> "IO" percentage is AFTER it in the top application.

The values are before them.

Busybox "top":
Mem: 237276K used, 8264K free, 0K shrd, 3292K buff, 90080K cached
CPU:  7.1% usr 21.4% sys  0.0% nice 71.4% idle  0.0% io  0.0% irq  0.0% softirq

It's a bit more clearer in procps "top":
top - 15:10:56 up 88 days,  4:13,  5 users,  load average: 0.23, 0.11, 0.04
Tasks: 129 total,   1 running, 126 sleeping,   2 stopped,   0 zombie
Cpu(s):  2.0%us,  0.5%sy,  0.0%ni, 97.2%id,  0.0%wa,  0.2%hi,  0.2%si,  0.0%st

(In reply to comment #84)
> (In reply to comment #83)
> Ok, so Home in general is working, but certain parts of it aren't.

Correct.

> One possibility is to install syslog (make sure you have enough space (several
> tens of MB) on root file system and remove it and /var/log/syslog* log files
> once you don't need it so that it won't fill your root fs).
> When the issue happens again, check whether there were any error messages from
> home:
>   grep hildon-home /var/log/syslog|tail -20
> (You need to be root to be able to access syslog files.)

Being a noob, I'm kind of afraid of using xterm a lot. I'll leave this as a
last option ☺

> > > What about IO percentage?  (i.e. is there a lot of swapping going on)
> > 
> > I don't know how to check it. Is it the upper two lines in top?
> > I haven't check there, but if I'll do it next time.
> It's the value before "io" in "top".

Top looks completely normal to me: 
Mem: 221828K used, 23712k free, 0K shrd, 5164K buff, 57460K cached
CPU: 9.7% usr 3,7% sys, 0,0% nice, 86.5% idle, 0.0% IO  0.0% IRQ 0.0% softir 
Load average 2.66 2.22 1.76

> >> If that means so called "Zombie" state,...
> > How can I know how many processes I have in that state?
> The "STAT" column in "ps" output contains "Z".  But that's unlikely reason. "D"
> state is more interesting (usually happens when processes are blocked due to
> slow disk access, swapping etc).

I found one D, followed by two Z, repeated twice. Let´s see what you think:
D sh -c hal-device bme | awk -F"[. ]" '$5 == "is chargi (And then the line is
over)
Z [hal-device]
Z [awk]

Hope this helps...

Comment 89 Eero Tamminen 2010-03-22 14:35:41 UTC

(In reply to comment #88)
> I found one D, followed by two Z, repeated twice. Let´s see what you think:
> D sh -c hal-device bme | awk -F"[. ]" '$5 == "is chargi (And then the line is
> over)
> Z [hal-device]
> Z [awk]

Something seems to be checking the battery charging state with command line
tools.  The called commands (hal-device & awk parsing it) have exited, but the
shell calling them is in deep sleep so it hasn't collected them.

Maybe this because program calling this shell command line isn't reading the
output from the pipe.

Have you something like battery-eye running?

(In reply to comment #89)
> Something seems to be checking the battery charging state with command line
> tools.  The called commands (hal-device & awk parsing it) have exited, but the
> shell calling them is in deep sleep so it hasn't collected them.
> Maybe this because program calling this shell command line isn't reading the
> output from the pipe.
> Have you something like battery-eye running?

After digging a little in maemo.org, I found out that the Desktop Command
Execution Widget uses that exact command when you're monitoring the battery. I
took it out from my desktops, but not enough time has passed to see if the
problem comes back. I'll report later.

Apart from Desktop Command Execution Widget (1.01), I'm running Battery Graph
(0.3.0).

nope its not the Desktop Command Execution Widget. i don't even have it
installed and have this issue

(In reply to comment #91)
> nope its not the Desktop Command Execution Widget. i don't even have it
> installed and have this issue
> 

We may have two differents reasons for the same bug then.
I changed the battery percentage for roots percentage and the bug has not
returned. I'm giving it more time, but as far as today it is solved for me.

Comment 93 Eero Tamminen 2010-04-08 17:01:03 UTC

I found an internal bug which mentions the same issue, so adding it here as a
reference, moving the bug to home as this appears in home and updating the
summary.

Note that this is not really a problem in hildon-home itself, but a bug in 3rd
party applets it loads and Maemo extras community QA process that accepts
leaking applets to the repository...

(In reply to comment #93)
> I found an internal bug which mentions the same issue, so adding it here as a
> reference, moving the bug to home as this appears in home and updating the
> summary.
> 
> Note that this is not really a problem in hildon-home itself, but a bug in 3rd
> party applets it loads and Maemo extras community QA process that accepts
> leaking applets to the repository...
> 

You sure?  I recently (about a week and a half ago) removed every single widget
from the desktop except for Ovi, and I think I just ran into this issue the
last couple of days.  At least, I think it was this issue, but unfortunately I
wasn't able to check out 'top' before I was forced to reboot it due to
non-responsiveness.

Comment 95 Eero Tamminen 2010-04-08 21:09:31 UTC

(In reply to comment #94)
>> Note that this is not really a problem in hildon-home itself, but a bug in
>> 3rd party applets it loads and Maemo extras community QA process that
>> accepts leaking applets to the repository...
> 
> You sure?  I recently (about a week and a half ago) removed every single
> widget from the desktop except for Ovi, and I think I just ran into this
> issue the last couple of days.

Did you also restart home? (otherwise you don't get rid of leaked memory)

> At least, I think it was this issue, but unfortunately I wasn't able
> to check out 'top' before I was forced to reboot it due to
> non-responsiveness.

Is home still/again non-responsive?

(In reply to comment #95)
> (In reply to comment #94)
> >> Note that this is not really a problem in hildon-home itself, but a bug in
> >> 3rd party applets it loads and Maemo extras community QA process that
> >> accepts leaking applets to the repository...
> > 
> > You sure?  I recently (about a week and a half ago) removed every single
> > widget from the desktop except for Ovi, and I think I just ran into this
> > issue the last couple of days.
> 
> Did you also restart home? (otherwise you don't get rid of leaked memory)

I did a cold reboot, so I would say so.

> > At least, I think it was this issue, but unfortunately I wasn't able
> > to check out 'top' before I was forced to reboot it due to
> > non-responsiveness.
> 
> Is home still/again non-responsive?

It's working fine now.  I've noticed that this happens every so often (usually
after about a week's worth of uptime or so).

This plays up after 2 (~48h) and/or 5 (~120h) days without any widgets and with
preinstalled the same issue. So a NO on 'only third party' problem

Comment 98 Eero Tamminen 2010-04-09 12:27:38 UTC

(In reply to comment #97)
> This plays up after 2 (~48h) and/or 5 (~120h) days without any widgets
> and with preinstalled the same issue. So a NO on 'only third party' problem

Your issue is _just_ home being slow on being topped (this bug), not rest of
the device being slow?


FYI: If the device memory usage grows enough that (e.g. "free" says) it's
constantly >200MB on swap, it starts to get slow[1].  Swap is on eMMC with 3rd
party applications, user's data & configuration files, many of the caches (e.g.
for thumbnails, Flash video[2] etc), tracker & SQLite databases...  Swap is on
its own partition, but that doesn't help much because with all this traffic
going through through the same eMMC HW interface, it can become a bottleneck.

If you see multiple processes in "top" being in "D" state, you have this
problem.

[1] In some rare cases where lots of pages are swapped out, BUT those pages are
not constantly used, you can have >1/2GB swapped without problems (use-cases
like zooming huge picture in images viewer or www-pages which contain hundreds
of MBs of uncompressed image data on them which are the reason for the large
swap), but in normal use-cases the swapped memory is also quite actively used
and then even 200MB swap can be an issue.

[2] If you get the slowdown with browser, adding memory card to the device may
help as Flash can use that as cache for streaming instead of the eMMC.

case1: device is idle (stby) no programs open, screen locked, a msg gets
received, the device plays the sound set but it is heavily scrambled.

case2: slide open device, it comes alive but nothing gets updated on screen for
about 2-3 seconds

case3: running a program, like browser trying to watch youtube, not possible
(no other programs started

all three cases get fixed with a restart of hildon-home (no third party
plugins/widgets running), home can in all cases be one of the 4 desktops, some
got widgets on it some not.

I tried to figure out if it is another program playing it... tried many
different cases with no success. If there is?! It is not its widget (looking at
all those background stuff running from browser and calendar, is alarmd not
enough?)

FYI most of the time wifi is on and I am logged into several accounts

Comment 100 Eero Tamminen 2010-04-12 11:22:37 UTC

(In reply to comment #99)
> case1: device is idle (stby) no programs open, screen locked, a msg gets
> received, the device plays the sound set but it is heavily scrambled.
> 
> case2: slide open device, it comes alive but nothing gets updated on screen
> for about 2-3 seconds
> 
> case3: running a program, like browser trying to watch youtube, not possible
> (no other programs started

What top shows happening in the device when case3 happens?
Any processes in D state?  What's using most of CPU?


> all three cases get fixed with a restart of hildon-home (no third party
> plugins/widgets running), home can in all cases be one of the 4 desktops,
> some got widgets on it some not.

Can you attach here following file:
  /proc/$(pidof hildon-home|cut -d' ' -f1)/smaps

from the state when you get this issue?

(From that I can see how much memory home is using and which applets it has
loaded, in case there's something that doesn't show up in the UI.)


> I tried to figure out if it is another program playing it... tried many
> different cases with no success. If there is?! It is not its widget
> (looking at all those background stuff running from browser and calendar,
> is alarmd not enough?)

If I remember correctly, the notification sound & showing are handled by
hildon-sv-notification-daemon.  I don't think Home is actually involved in
that.

Kimmo?


> FYI most of the time wifi is on and I am logged into several accounts

(In reply to comment #100)
> > case3: running a program, like browser trying to watch youtube, not possible
> > (no other programs started
> 
> What top shows happening in the device when case3 happens?
> Any processes in D state?  What's using most of CPU?

mmh seems to work well not perfect but not as bad as last time I checked
no D states and cpu in order browserd, pulseaudio, xorg, pulseaudio, browserd
(3x).

Wierd now... after I tried a youtube video everything is like behaving normal
again.

> 
> > all three cases get fixed with a restart of hildon-home (no third party
> > plugins/widgets running), home can in all cases be one of the 4 desktops,
> > some got widgets on it some not.
> 
> Can you attach here following file:
>   /proc/$(pidof hildon-home|cut -d' ' -f1)/smaps

done

> from the state when you get this issue?
> 
> (From that I can see how much memory home is using and which applets it has
> loaded, in case there's something that doesn't show up in the UI.)
> 
> 
> > I tried to figure out if it is another program playing it... tried many
> > different cases with no success. If there is?! It is not its widget
> > (looking at all those background stuff running from browser and calendar,
> > is alarmd not enough?)
> 
> If I remember correctly, the notification sound & showing are handled by
> hildon-sv-notification-daemon.  I don't think Home is actually involved in
> that.

confirmed, sound plays up randomly and is not considered to be an issue
connected to this bug

Created an attachment (id=2603) [details]
smaps

this attachement was taken when touchscreen was unresponsive for a couple of
seconds (totaly, tried to close a program after I slide out the kbd)

Sorry for the notification spam because of the file type changes.

I just tried around a bit watching top over ssh and recognized that for about
two seconds hildon-desktop and xorg are on top fo the list.

By just pushing the power button on a stby device I get many processes
changeing from 'S' to 'D' for about 2-4 seconds. If that happens the
unlockslider does not show at first.
'D' showing for
/usr/bin/hildon-home
/usr/sbin/browserd -s 17229 -n RTComMessagingServer
/usr/sbin/browserd -s 17123 -n browserui
/usr/bin/rtcom-messaging-ui
/usr/bin/osso-addressbook
/usr/bin/Calendar
/usr/bin/browser
/usr/bin/modest
/usr/bin/image-viewer
/usr/bin/camera-ui
/usr/bin/worldclock
/usr/lib/telepathy/telepathy-haze
/usr/bin/mediaplayer
/usr/bin/intellisyncd -u 29999 -a
/usr/lib/tracker/trackerd
/usr/lib/tracker/tracker-indexer
/usr/bin/osso-abook-home-applet
/usr/sbin/browserd -d
/sbin/mce --force-syslog
/usr/bin/location-proxy --no-detach
/usr/bin/mafw-dbus-wrapper mafw-tracker-source
and lots more

could try to catch all if needed be (its just a 4 second slot and it does not
happen everytime)

Comment 104 Eero Tamminen 2010-04-16 11:17:07 UTC

(In reply to comment #102)
> Created an attachment (id=2603) [details] [details]
> smaps
> 
> this attachement was taken when touchscreen was unresponsive for a couple of
> seconds (totaly, tried to close a program after I slide out the kbd)

For the memory usage, timing is rarely relevant.  It's usually enough to take
the data right after the problem.

Home memory usage is large, heap alone is tens of MB:
00016000-015f3000 rw-p 00016000 00:00 0          [heap]
Size:              22388 kB
Rss:               15832 kB
Pss:               15824 kB
Shared_Clean:          8 kB
Shared_Dirty:          0 kB
Private_Clean:       700 kB
Private_Dirty:     15124 kB
Referenced:        10596 kB
Swap:               6504 kB

It's all dirtied and 15MB(!) of it seems to be active.

You have in home a python interpreter and following plugins
(i.e. stuff in /usr/lib/hildon-desktop/):
- calendar-home-applet.so
- connui-cellular-operator-home-item.so
- countdown-home-widget.so
- desktop-cmd-exec.so
- libforecaweather.so.1
- libmediaplayerhomeapplet.so
- lib-simple-fmtx-widget.so.0.0.0  (optified)
- loaders/libpythonpluginloader.so

I think the main issue is Python and whatever brings it into Home (fmtx
applet?).  Using things like Python for always running processes is a really
bad idea. Python increases the memory usage significantly and normally one
doesn't get rid of almost any memory usage increases created by it (due to
memory fragmentation), even if the Python code itself would free it.

Get rid of Python in Home *and* restart Home to get rid of the memory usage, I
think Home should behave much better after that.  To verify that you got rid of
python, you can do:
  grep python /proc/$(pidof hildon-home|cut -d' ' -f1)/maps
(If it doesn't report anything, you should be fine.)

Note that according to above comments/analysis, there are also other,
non-Python applets which cause issues (leak a lot and keep the memory active).
Avoid them too.


(In reply to comment #103)
> Sorry for the notification spam because of the file type changes.
> 
> I just tried around a bit watching top over ssh and recognized that for about
> two seconds hildon-desktop and xorg are on top fo the list.

I guess something else had pushed them to swap, this can make the device quite
slow.  Because their memory usage depends completely on the number of
applications and what they do, it's not possible to just give them whatever
memory they need.


> By just pushing the power button on a stby device I get many processes
> changeing from 'S' to 'D' for about 2-4 seconds.

I think that's done by the policy manager.  When you press power button, other
processes are suspended to make sure that you can actually get the power menu. 
From power menu you can (cleanly) shut down the device, do (e.g. an emergency)
phone call, or kill a badly behaving top application, so it's important that it
works fine.


> If that happens the unlockslider does not show at first.

I assume policy manager keeps the other processes suspended until power menu
process (it takes care of the unlock slider too) comes up.

I guess it was swapped out and lot of other processes needed to be swapped out
instead to get it in.  Power menu process shouldn't be that large though. 
Could you provide also following smaps files:
  /proc/$(pidof mce)/smaps
  /proc/$(pidof systemui)/smaps
?

(First one is daemon monitoring things like power key, latter is the power menu
UI.)

(In reply to comment #104)
>   grep python /proc/$(pidof hildon-home|cut -d' ' -f1)/maps
> (If it doesn't report anything, you should be fine.)

removing all widgets from desktop, uninstalling anything what was shown like
the operator name widget and stuff gives me

root@cassiopeia:~# grep python /proc/$(pidof hildon-home|cut -d' ' -f1)/maps
410e7000-410ea000 r-xp 00000000 fe:01 137600    
/usr/lib/hildon-desktop/loaders/libpythonpluginloader.so
410ea000-410f1000 ---p 00003000 fe:01 137600    
/usr/lib/hildon-desktop/loaders/libpythonpluginloader.so
410f1000-410f2000 rw-p 00002000 fe:01 137600    
/usr/lib/hildon-desktop/loaders/libpythonpluginloader.so
41baa000-41c9f000 r-xp 00000000 fe:01 61173      /usr/lib/libpython2.5.so.1.0
41c9f000-41ca6000 ---p 000f5000 fe:01 61173      /usr/lib/libpython2.5.so.1.0
41ca6000-41cc9000 rw-p 000f4000 fe:01 61173      /usr/lib/libpython2.5.so.1.0

is this a standard set loaded anyways or do I still miss-out on something
because putting everything back together gives me the same result.
The output before I removed all was huge though.

> 
> I think that's done by the policy manager.  When you press power button, other
> processes are suspended to make sure that you can actually get the power menu. 
> From power menu you can (cleanly) shut down the device, do (e.g. an emergency)
> phone call, or kill a badly behaving top application, so it's important that it
> works fine.
> 
> 
> > If that happens the unlockslider does not show at first.
> 
> I assume policy manager keeps the other processes suspended until power menu
> process (it takes care of the unlock slider too) comes up.

sorry I meant locked device (stby is refered to as display on but on desktop
right?)

> I guess it was swapped out and lot of other processes needed to be swapped out
> instead to get it in.  Power menu process shouldn't be that large though. 
> Could you provide also following smaps files:
>   /proc/$(pidof mce)/smaps
>   /proc/$(pidof systemui)/smaps

attaching

Created an attachment (id=2604) [details]
smaps-mce

Created an attachment (id=2605) [details]
smaps-systemui

since I have the same bug, I'm trying to get the same files, but when I do any
of 
/proc/$(pidof mce)/smaps
/proc/$(pidof systemui)/smaps
/proc/$(pidof hildon-home|cut -d' ' -f1)/smaps

It says 
/bin/sh: /proc/XXXX/smaps: Permission Denied. (Where XXXX is a different number
for each of the lines above)

I've tried with and without root and same result.

I did grep python /proc/$(pidof hildon-home|cut -d' ' -f1)/maps and it said
nothing. just jumped to the next line.

Cheers,

(In reply to comment #108)
> since I have the same bug, I'm trying to get the same files, but when I do any
> of 
> /proc/$(pidof mce)/smaps
> /proc/$(pidof systemui)/smaps
> /proc/$(pidof hildon-home|cut -d' ' -f1)/smaps

do

cat /proc/$(pidof mce)/smaps > smaps-mce-carlos
cat /proc/$(pidof systemui)/smaps > smaps-systemui-carlos
cat /proc/$(pidof hildon-home|cut -d' ' -f1)/smaps > smaps-hildon-home-carlos

as root and you are fine to upload the files you just created from the path
where you entered the command

on the device the browser cannot go into /root/ so you might change directory
before you enter the commands (cd /home/user/MyDocs/)

Comment 110 Eero Tamminen 2010-04-16 17:17:04 UTC

(In reply to comment #105)
> (In reply to comment #104)
> >   grep python /proc/$(pidof hildon-home|cut -d' ' -f1)/maps
> > (If it doesn't report anything, you should be fine.)
> 
> removing all widgets from desktop, uninstalling anything what was shown like
> the operator name widget and stuff gives me
> 
> root@cassiopeia:~# grep python /proc/$(pidof hildon-home|cut -d' ' -f1)/maps
> 410e7000-410ea000 r-xp 00000000 fe:01 137600    
> /usr/lib/hildon-desktop/loaders/libpythonpluginloader.so
[...]

Ok, so you still have something pulling python in.

This would tell whether some of the libs/applets in home is linking python
stuff:
-------
map=/proc/$(pidof hildon-home|cut -d' ' -f1)/maps;
for lib in $(egrep '.*\.so' $map|cut -d/ -f2-|sort -u); do
        echo "* /$lib:";
        /lib/ld-2.5.so --list /$lib|grep python;
done
-------

(It lists all the libraries linked into home currently and for things using
python prints ldd line about that.)


> is this a standard set loaded anyways or do I still miss-out on something
> because putting everything back together gives me the same result.

But reading what google found...
  http://www.gossamer-threads.com/lists/maemo/developers/57076

It's possible that it gets automatically loaded if it's installed, even without
any applet using it. You could try just:
  apt-get autoremove hildon-desktop-python-loader

I.e. remove it completely from the device.


>> I guess it was swapped out and lot of other processes needed to be swapped >> out instead to get it in.  Power menu process shouldn't be that large
>> though. Could you provide also following smaps files:
>>   /proc/$(pidof mce)/smaps
>>   /proc/$(pidof systemui)/smaps
> 
> attaching

No problem in them.


(In reply to comment #108)
> I did grep python /proc/$(pidof hildon-home|cut -d' ' -f1)/maps and it said
> nothing. just jumped to the next line.

Then you don't have python stuff in Home.  I.e. your Home slowdown for you
comes from some other applet (see comments above).

You may also have some other huge process in the device that may be making it
slow, especially if it besides being leaking a lot, wakes constantly up on the
background (as much as its allowed).

(In reply to comment #110)
>   apt-get autoremove hildon-desktop-python-loader
recaller was uninstalled too, thought that was a program link but I recognized
it was found under widgets. so everything is now back to what it was before but
recaller!!!

I am not sure if the problem was there before I installed recaller. I will now
wait for it to play up again.

There are no libs related to python anymore and maps grep doesnt show anything
from python too. (fingers crossed)

A policy edit to make sure there is the programming language written in the
description would be nice ;). I try to get around all those trouble programs
but you never know.

Comment 112 Eero Tamminen 2010-04-16 18:42:37 UTC

(In reply to comment #111)
> A policy edit to make sure there is the programming language written in the
> description would be nice ;).

Python isn't so much of a problem for applications that user just runs and then
closes.

Applets using python have "Type = python" in their .desktop files.


> I try to get around all those trouble programs but you never know.

I can understand that it can be quite hard for community QA to catch harmful
resource leakage that happens during several days.  I would personally propose
using the new package for a day and taking occasional endurance snapshots so
that one sees next day whether there was any serious leakage.

Unfortunately we don't have any nice & good GUI for them for this, currently
they would need to do it from command line (it's easy, but requires root).

Created an attachment (id=2650) [details]
smaps-hildon-home

Created an attachment (id=2651) [details]
smaps Systemui

I got the error yesterday again. I'm attaching the mentioned files (For some
reason mce came empty, and I didn't realize 'til today).
I have no clue how to interpret them, so I hope you can give a hand.
Best regards,

Comment 116 Eero Tamminen 2010-04-23 11:11:00 UTC

(In reply to comment #115)
> I got the error yesterday again. I'm attaching the mentioned files (For some
> reason mce came empty, and I didn't realize 'til today).

You need root rights to get mce data.


> I have no clue how to interpret them, so I hope you can give a hand.

But mce & system-UI seemed fine so the home SMAPS data is enough.

Your home process heap is huge:
00016000-0275b000 rw-p 00016000 00:00 0          [heap]
Size:              40212 kB
Rss:               33048 kB
Pss:               33016 kB
Shared_Clean:          8 kB
Shared_Dirty:         28 kB
Private_Clean:       364 kB
Private_Dirty:     32648 kB
Referenced:        32688 kB
Swap:               7044 kB

32MB active, 7MB in swap.


Your home applets seem to be:
- connui-cellular-operator-home-item.so
- calendar-home-applet.so
- conversations-inbox-widget.so
- libgooglesearchwidget.so
- libmediaplayerhomeapplet.so
- libovipromotionwidget.so
- personal-photo-frame.so
- system_info.so
- libtunewikiapplet.so

(One of them is also bringing in:
- loaders/libqtpluginloader.so)


I guess one or several of the applets are leaking.  You need to find out which
one.

If connui-cellular-operator-home-item.so applet is something called "Custom
Operator Name Widget" mentioned in comment 66, at least that one is causing
this kind of issues.

If removing that and restarting home doesn't help, you need to do additional
checks.  Best is using binary search:
- Disable half of the 3rd party[1] ones
- restart home (see above how to do that) to get clean slate
- wait few days to see whether the problem re-occurs.

If the problem happens again, disable again half of the remaining ones and try
again.  If the problem didn't happen, add back half of what you removed and try
again.  Repeat until you know which applet(s) are causing the problem.

[1] Home itself and Nokia's pre-installed applets have been tested not to leak.


PS. Once you find out which 3rd party applet is causing the issue, please
comment on its download page or otherwise complain about it to its author.

Few nights ago I had another unresponsive desktop, means I could switch between
desktops and was able to use the menu button but all icons/widgets were frozen,
no updates of widgets and not even app-shortcuts were click-able. I ran out of
battery that night so wasn't able to look out for issues causing it. Few days
before the desktops were slow and the only process obviously on load was the
xserver itself, hildon-desktop and home were doing fine so no ram leakage or
something, the issue disappeared after a few minutes but the mediaplayer widget
stayed unresponsive. It shows the current track playing and does start the
mediaplayer but the hot-buttons rew-play/pause-fwd do light up on push but dont
do anything. Not even a restart helped it. 

Removing the widget and adding it again emptied the whole desktop for a few
seconds, guess it restarted for some reason, and the only widgets appearing
again are the mediaplayer(works now) and calendar(no events or tasks). This is
current state I leave the device and wait for your response.

Comment 118 Eero Tamminen 2010-04-26 16:13:50 UTC

(In reply to comment #117)
> Few nights ago I had another unresponsive desktop, means I could switch
> between desktops and was able to use the menu button but all icons/widgets
> were frozen, no updates of widgets and not even app-shortcuts were 
> click-able.

This means that hildon-home is frozen, the menu button and panning are done
with hildon-desktop.


> I ran out of
> battery that night so wasn't able to look out for issues causing it. Few days
> before the desktops were slow and the only process obviously on load was the
> xserver itself, hildon-desktop and home were doing fine so no ram leakage or
> something,

To see whether something is drawing things to its window (e.g. in background),
you can use "xresponse -w 0 -a '*'":
  http://wiki.maemo.org/Documentation/devtools/maemo5/xresponse


> the issue disappeared after a few minutes but the mediaplayer widget
> stayed unresponsive. It shows the current track playing and does start the
> mediaplayer but the hot-buttons rew-play/pause-fwd do light up on push but
> dont do anything. Not even a restart helped it. 

This could be an issue with the mafw-playlist-daemon or mafw-dbus-wrapper
processes.  If this happens again, take SSH connection to your device and check
what "dbus-monitor --session" reports when you press the Mediaplayer applet
buttons.


> Removing the widget and adding it again emptied the whole desktop for a few
> seconds, guess it restarted for some reason, and the only widgets appearing
> again are the mediaplayer(works now) and calendar(no events or tasks). This is
> current state I leave the device and wait for your response.

I assume some of these 3rd party widgets you had caused hildon-home to crash. 
When hildon-home is re-started like that, it will disable all 3rd party applets
to prevent crash-restart cycle.  Smaps file from the hildon-home process would
verify this.

With only applets in Home that come pre-installed with the device, you don't
get the issue mentioned in this bug.

I'm not sure if this is the same bug, but I experienced the following:
hildon-home eating all CPU, desktop being unresponsive, no icons whatsoever
visible on the desktop, and trying to close a missing call notification brought
up a "do you want to kill hildon-home" dialog.

I eventually found /home/user/.config/hildon-desktop/notifications.db, which is
about 50 MB on my device. I replaced it with a copy with the notifications
table emptied, and killed hildon-home. After that, it came up successfully
(i.e. icons back on the desktop), and is now not eating up all CPU anymore.

I'm sorry that I can't provide a copy of the notifications.db file, it was
fairly hard to do anything with the device in this state, but maybe this also
fixes the problem for someone else.

Comment 120 Eero Tamminen 2010-05-04 10:11:54 UTC

(In reply to comment #119)
> I'm not sure if this is the same bug, but I experienced the following:
> hildon-home eating all CPU, desktop being unresponsive, no icons whatsoever
> visible on the desktop, and trying to close a missing call notification
> brought up a "do you want to kill hildon-home" dialog.
> 
> I eventually found /home/user/.config/hildon-desktop/notifications.db,
> which is
> about 50 MB on my device. I replaced it with a copy with the notifications
> table emptied, and killed hildon-home. After that, it came up successfully
> (i.e. icons back on the desktop), and is now not eating up all CPU anymore.

Did you test that killing desktop alone wasn't enough to get rid slowdown
(by getting rid of leaks from the 3rd party applets)?


> I'm sorry that I can't provide a copy of the notifications.db file, it was
> fairly hard to do anything with the device in this state, but maybe this also
> fixes the problem for someone else.

Please tell after few days whether the slowdown comes back and if yes, has the
notification DB again grown that much again...


Maybe you could run also:
  find /home/user/ -name '*.db'|xargs du|sort -n

To check whether you have any other huge databases?

Comment 121 Kimmo Hämäläinen 2010-05-04 11:30:58 UTC

(In reply to comment #120)
...
> > I eventually found /home/user/.config/hildon-desktop/notifications.db,
> > which is
> > about 50 MB on my device. I replaced it with a copy with the notifications
> > table emptied, and killed hildon-home. After that, it came up successfully
> > (i.e. icons back on the desktop), and is now not eating up all CPU anymore.
> 
> Did you test that killing desktop alone wasn't enough to get rid slowdown
> (by getting rid of leaks from the 3rd party applets)?

You mean hildon-home, not (hildon-)desktop...  hildon-desktop does not have ANY
plugins whatsoever. I repeat: no plugins in hildon-desktop! :)

The path name of the notifications database comes from Diablo times when
hildon-desktop had plugins and implemented the Notification service. In N900,
it doesn't, and I'm damn glad it does not, seeing all the brain-damaged
3rd-party plugins written by 5-year-olds around...

Created an attachment (id=2695) [details]
custom-operator-name-widget patch to use less CPU

I sent this patch to Faheem Pervez (author of custom-operator-name-widget). It
should make hildon-home use a bit less of CPU when the device is unlocked. The
rationale is in the patch.

I noticed that only happens on days in which to set the phone wake up by the
alarm. After a few hours the phone gets really slow and unusable, watching the
processes by conky I see that the CPU is 100%, and there are various processes
20 to 40%. sorry for english from google translate...

Once it happened that the phone had become unusable, I tried restart and
appeared a white screen with green writing: Malfunction, the phone shutdown in
10s O_O

Example process right now:
hildon-home @ 40%
Facebook @ 20%
dbus-deamon @ 15%
Xorg @ 12%

when it happens, my phone is on standby, I notice that there is something wrong
when I feel it is hot (100% CPU), I see that the battery goes down quickly, and
obviously the screen is not responding or responding slowly. to unlock the
screen I use 3 to 4 times the side lever.

I'm running PR 1.2 firmware..

Personally I can easily reproduce the bug (frozen screen) : I just have to
launch the phone application when portrait mode is save.
(sorry for my bad english)

in this setting :
http://img20.imageshack.us/img20/9636/screenshot2010061422423.png

Strangely, if I choose landscape mode and save it, I have no problem and
everything is going right.

Then finally portrait phone missed me a lot.

Comment 125 Andre Klapper 2010-06-17 13:44:30 UTC

According to Nokia's testing this can be reproduced in 10.2010.19-1 with the
following stepsÖ
1. Remove the Facebook widget from the desktop but leave it installed. 
2. cd /home/user/.feedservice2/facebook
3. remove the facebook.db file and the image-cache directory with rm -rf
4. Connect to Wifi that does not provide any connectivity like a public wifi 
   hotspot without authenticating.
5. Re-add Facebook widget to the desktop and now facebook, feedservice and
hildon-home are using the cpu to 64%.
6. Remove Facebook from the desktop and hildon-home is now using 98% of the
CPU.

Nokia decided that this bug is closed as WONTFIX, since there is a known
problem on the feedservice applet, and no possible fix or workaround done from
the application framework side (since the applet support process needs to be
restarted - just restarting hildon-home is not enough).

I haven't had this bug for a while (I eliminated the problematic widgets), but
I never had Facebook Applet installed.
This is a common bug, that happens under several circumstances. Maybe the
Facebook issue is a won't-fix, but the bug as itself is far from being fixed.
Regards,

(In reply to comment #126)
> I haven't had this bug for a while (I eliminated the problematic widgets), but
> I never had Facebook Applet installed.

Ditto. I have never installed the Facebook applet but have regularly
experienced this non-responsive behaviour since upgrading to PR1.2.

Comment 128 Kimmo Hämäläinen 2010-06-17 14:16:30 UTC

(In reply to comment #127)
> (In reply to comment #126)
> > I haven't had this bug for a while (I eliminated the problematic widgets), but
> > I never had Facebook Applet installed.
> 
> Ditto. I have never installed the Facebook applet but have regularly
> experienced this non-responsive behaviour since upgrading to PR1.2. 

Which applets you have active then?

I don't even have a FB account so I never installed this widget.
And I've seen this behaviour more then once with PR 1.2.

This bug is for sure not fixed in my opinion.

(In reply to comment #125)
> [bug can be reproduced messing with facebook widget]

> Nokia decided that this bug is closed as WONTFIX, since there is a known
> problem on the feedservice applet

What is the known problem?  How is it related to the steps-to-reproduce?  Is
the general symptom really related to just that known problem?

> the applet support process needs to be
> restarted

Which applet support process?  Would a workaround just be to restart said
process every six hours?

Comment 131 Kimmo Hämäläinen 2010-06-17 14:23:53 UTC

All (well, 99%) applets live inside the hildon-home process. It is also
possible to show an applet window without using hildon-home, though.

The problem is that ANY APPLET can stop hildon-home for any number of seconds,
e.g. when it's waiting for data from the Internet.

It's very very likely that some applet is to blame for this blocking of the UI.
So that's why it is very essential to know exactly which applets you have
running there.

(In reply to comment #125)
> According to Nokia's testing this can be reproduced in 10.2010.19-1 with the
> following stepsÖ
> 1. Remove the Facebook widget from the desktop but leave it installed. 
> 2. cd /home/user/.feedservice2/facebook
> 3. remove the facebook.db file and the image-cache directory with rm -rf
> 4. Connect to Wifi that does not provide any connectivity like a public wifi 
>    hotspot without authenticating.
> 5. Re-add Facebook widget to the desktop and now facebook, feedservice and
> hildon-home are using the cpu to 64%.
> 6. Remove Facebook from the desktop and hildon-home is now using 98% of the
> CPU.
> 
> Nokia decided that this bug is closed as WONTFIX, since there is a known
> problem on the feedservice applet, and no possible fix or workaround done from
> the application framework side (since the applet support process needs to be
> restarted - just restarting hildon-home is not enough).
> 

This isn't my issue either. I have had the facebook widget uninstalled since
reflash and never used it. I'm still testing widgets to see which one brings
back the issue, but it seems again, that the problem widget is "Battery", since
I removed that, I haven't had the lockup, yet it hasn't been that long and the
only other widget I have running is the "System Info Widget".

Comment 133 Andre Klapper 2010-06-17 15:25:26 UTC

(Please do not fullquote the complete previous comment but instead strip
lines.)

The Facebook issue was one example for how to produce this issue. It does not
mean that it is the one and only way to trigger the described outcome.

(In reply to comment #124)
> Personally I can easily reproduce the bug (frozen screen) : I just have to
> launch the phone application when portrait mode is save.
> (sorry for my bad english)
> 
> in this setting :
> http://img20.imageshack.us/img20/9636/screenshot2010061422423.png
> 
> Strangely, if I choose landscape mode and save it, I have no problem and
> everything is going right.
> 
> Then finally portrait phone missed me a lot.
> 
Problem solved for me :

Until then, I was settling the problem temporarily by checking the landscape
mode in the phone app like I said, but now it seems to be completely resolved
since I deleted "Command Execution Desktop Widget".

> (In reply to comment #125)
> > [bug can be reproduced messing with facebook widget]
> 
> > Nokia decided that this bug is closed as WONTFIX, since there is a known
> > problem on the feedservice applet
> 

What is the known problem?  How is it related to the steps-to-reproduce?  Is
the reported symptom really related to just that known problem?

> > the applet support process needs to be
> > restarted
> 

Which applet support process?  Would a workaround just be to restart said
process every six hours?

(In reply to comment #135)
> > (In reply to comment #125)
> > > [bug can be reproduced messing with facebook widget]
> > 
> > > Nokia decided that this bug is closed as WONTFIX, since there is a known
> > > problem on the feedservice applet
> > 
> 
> What is the known problem?  How is it related to the steps-to-reproduce?  Is
> the reported symptom really related to just that known problem?

There are more problems but all known and they all have nothing to do with
hildon-home. One is that python-applets can leak, making the device swap and
that makes it unresponsive or even freeze for a short (in case of seconds up to
minutes in some cases) period of time. A second is that any applet can freeze
hildon-home due to waiting for another process . A third is that another
program running in background eats the device or home.
Which I had all at some point. The first was recaller the second was OMweather
the I don't know yet... came twice but is gone now some like over a week.

> > > the applet support process needs to be
> > > restarted
> > 
> 
> Which applet support process?  Would a workaround just be to restart said
> process every six hours?
> 
/usr/bin/feedservice2
/usr/bin/facebook

as I cannot reproduce this for some reason I can't tell if a restart of the
three would help, maybe someone else can try! procedure is

pkill feedservice2
sleep 5
dsmetool -k /usr/bin/hildon-home
sleep 5
dsmetool -t /usr/bin/hildon-home

the sleeps are just to be save as facebook will be killed if feedservice2 isn't
running anymore (don't know what it does but the process disappears).
Don't set it up as cron initially please, try it on a device playing up with
that faulty behavior as I wasn't able to try it!!!

with dsmetool -t /usr/bin/hildon-home home is loaded and if the widget is still
on home it will start feedservice and facebook by itself.

I'd like to open this up as 'triggered' by call again. If you like me to file a
new one just tell.

I recognized it a while ago but wasn't that sure if it was a call or something
else. Maybe it is something else but it's none of the widgets afaict. I rang a
friend yesterday afternoon, opened the phone via shortcut from desktop, after I
hang up I wanted to edit the contact's details by opening the phonebook from
desktop aswell but it was in freeze again. Uptime is now +8days  so I guess it
is not related to the previous 2-4days repeating home hick-up. That phone-app
makes stuff trigger we saw before with mediaplayer starting playback after a
call was ended. Don't know if it's a bug in pulseaudio as it is still
scrambling, stuttering or playing no sound at all from time to time.

Comment 138 Kimmo Hämäläinen 2010-06-28 13:00:32 UTC

fixer of this bug needs enough information to reproduce the problem, it's
pointless to report bugs if you cannot provide this much information. Saying
that "it happens when I get a call" is not enough to reproduce this because
everybody gets calls all the time and don't have this problem...

A new bug with steps to reproduce, and contents of /etc/hildon-desktop/*, and
"dpkg -l" listing attached would help to determine the offending applet.

Based on my software development experience and taking into account a lot of
similar bugs about "non-responsiveness" I am sure that all that bugs are just
lack of memory. 256MB is not enough for system which has a typical real-time
application size from 60MB to 120MB (pulseaudio, gstreamer, thumbnailerd,
modest + addressbook).

Swap space on flash actually is pretty slow for that sizes - it runs around
11MB/sec - 10 secs just to swap out the thumbnailerd! And combining
applications in memory cgroups (to restrict memory usage) is not finished well.

So, we got all that "out of memory" (for exam - 7372) in different applications
and the same time - non-responsiveness like 6605, "Answer button on BT doesn't
answer a call" or this one.


To fix it Nokia could work with more attention with memory cgroups and separate
a real-time applications from non-realtime (like browser or modest). Just
allocate some space for phone/BT/basic GUI and keep it under control - don't
give that space for non-realtime apps.

Special case is with widgets and hildon-home - it looks like it needs a
redesign to split a non-realtime widget stuff from real-time window manager
(which IS NEEDED for real-time apps).


OK, that is a dream...

Hi Guys,

 I am facing the exact issue of N900 getting non-responsive after 48 hours of
uptime. The issue is continuously reproducible every 48 hours and I am not able
to zero in on the exact cause.... Why are people still not able to reproduce
the issue when so many users have reported the same. this is a very critical
bug and needs to be fixed..restarting N900 every two days is just a not a
proper solution..

I have disabled all widges,shortucts on desktop but still the issue is there..

For more reports of this issue please see :
http://talk.maemo.org/showthread.php?t=42960&page=1

hoping for a quick resolution.

Thanks
Bipin




For

Comment 141 Kimmo Hämäläinen 2010-06-30 10:01:47 UTC

if the whole N900 UI is unresponsive, that is different problem than this bug
report describes. This bug is about jammed hildon-home process.

What is the difference?

Comment 143 Kimmo Hämäläinen 2010-07-01 09:40:22 UTC

(In reply to comment #142)
> What is the difference? 

The difference is of course the place where the fix should be. As you can see,
the Bugzilla component is "Home" for hildon-home/status-menu/desktop.  Device
lockup sounds like a kernel problem (SGX lockup?), or a wild process (did you
check "top"?).

Sorry, but I am asking about - what difference can be in bug report? What is a
crucial difference for regular user to recognize hildon-home lock and device
lock?

(In reply to comment #144)
> Sorry, but I am asking about - what difference can be in bug report? What is a
> crucial difference for regular user to recognize hildon-home lock and device
> lock?
> 

Yes egoshin....You are correct.for the end user its actually a device lock
which he sees..I am after this issue for quite a long time.. Being a developer
myself I can very well identify that there is a issue which causes the
hildon-home to lock up after an uptime > 48 hours..i can consistently reproduce
the issue..

This time i tried by running the n900 without a sim and also had the load
applet uninstalled..I have almost uninstalled all third party apps in pursuit
of this issue.. But i just simply find one cause which slows down the
hildon-home..the severity is exteme when we get notifications(message or call)
or when the device wakes up ..

the python-hildon updates, see at apt-get update && apt-get upgrade, are
related to this bug?

Comment 147 Kimmo Hämäläinen 2010-07-02 09:42:37 UTC

(In reply to comment #144)
> Sorry, but I am asking about - what difference can be in bug report? What is a
> crucial difference for regular user to recognize hildon-home lock and device
> lock?

hildon-home is handling the Home shortcuts and Home widgets/applets you have on
your desktop(s). You can remove hildon-home and still start programs, switch
between them etc. because these functions are in the hildon-desktop process. So
if only your applets/shortcuts are jammed, it's not the same as the whole UI is
jammed.