[maemo-developers] [maemo-developers] Maemo 2.0 device reboot

[From: Eero Tamminen]

Hi,

ext Marius Gedminas wrote:
>>>> Hi, after upgrade to maemo 2.0 I have a problem. Some times my 770
>>>> reboot. This happen some times when I'm using the browser and every
>>>> time I try to use Gizmo. For now I never had problem with other
>>>> programs. You think this is a software problem or hardware?
>>> My 770 reboots once every two--three days.  I think it's a software
>>> problem.  I could be wrong.
>> As mentioned in the following link, please file bugs against the errant
>> applications.
>> http://maemo.org/maemowiki/ReportingRebootIssues?action=show
>>
>> I remember in your case it was FBReader - report it to them.
> 
> /var/lib/dsme/lifeguard-resets claims it is maemo_af_desktop's fault.

Were there several reboots accounted for the Desktop process?

Btw. there are several reasons why Desktop might die:
- It's buggy :-)
- Something in the device is forcing it to run completely out of memory
  (and if alloc fails, Glib will abort the co. process), e.g. because
  that something is leaking memory or otherwise using a lot of memory
  without integrating itself to the device memory management:
  - If possible, app should implement support for the "background killing"
    i.e. save UI state when backgrounded and then indicate[1] that it's
    killable when the device runs out of memory:
    https://stage.maemo.org/svn/maemo/projects/haf/doc/api/hildon-libs/hildon-libs-HildonProgram.html#hildon-program-set-can-hibernate
    http://www.maemo.org/platform/docs/api/libosso/html/group__Statesave.html
    http://www.maemo.org/platform/docs/api/libosso/html/group__Autosave.html
    When foregrounded, I think app should then remove the state and
    when being re-started, it should check whether there was some
    UI-state.  If there was, restore the UI-state (instead of going
    to the default application state).  If you strace the device apps,
    you see that UI state is stored under /tmp/osso-appl-states/ which
    is on tmpfs i.e. goes away at reboot
  - It could use the libosso osso_mem_saw_enable & osso_mem_saw_disable
  	http://maemo.org/lxr/source/libosso/src/osso-mem.h#110
    functions around operations that:
    - could potentially take a lot of memory (loading large image etc)
    - handle allocation failures gracefully (not abort/assert)
  - If app caches things or otherwise has some "optional" memory
    usage, it could also listen to the system low memory notifications
    so that it can purge from RAM all of its caches when that happens:
    http://www.maemo.org/platform/docs/api/libosso/html/group__Devstate.html
    http://www.maemo.org/platform/docs/api/libosso/html/group__outside.html#g231284109a21410088850beed324ea57

If the device runs _completely_ out of memory, I don't think the kernel
out-of-memory killer knows which process user would prefer to be killed
to get more memory :-).

Some more info on kernel OOM-killer:
   	http://linux-mm.org/OOM_Killer
	http://lwn.net/Articles/104179/

[1] You can check whether app is "background-killable" by:
- using "xwininfo|grep Window id" and tapping to the application window,
- topping another window, and then
- doing "xprop -id <id> | grep KILL"
If you see the hibernate property set for the app,
it is "background killable".


> FBReader just happens to be the application I use most often.
> 
> I haven't reported it in Bugzilla yet, because I do not have a way to
> reproduce the problem (other than "try to use the device for a few
> days"), and also because it is not that irritating -- the device boots
> pretty fast, and the progress bar is kinda nice.  :)


  - Eero