maemo.org Bugzilla – Bug 3610
Modest stays in RAM after being closed although it's not set to check mails
Last modified: 2009-11-04 18:59:15 UTC
You need to
before you can comment on or make changes to this bug.
when i close modest and check running processes using load-applet, i find that
modest is still hanging around. further investigation seems to indicate that
i do not have it set to check for new mail at intervals so i would expect it to
fully close when i close the windows.
also, killing it in this state seems to make it forget what mails and similar i
had deleted the last time i had it open.
This doesn't happen after reflash when Modest doesn't have any accounts set up.
Is there anything specific about the accounts you've set up and do you have
oops, forgot about that.
there are two pop accounts. set to download headers only.
beyond that i cant think of anything special about them.
here is something i was told to add:
/proc/3105/task/3105/status:State: S (sleeping)
/proc/3105/task/3106/status:State: S (sleeping)
/proc/3105/task/3107/status:State: S (sleeping)
/proc/3105/task/3108/status:State: S (sleeping)
/proc/3105/task/3109/status:State: S (sleeping)
/proc/3105/task/3110/status:State: S (sleeping)
/proc/3105/task/3111/status:State: S (sleeping)
im not 100% how long after i last used modest that this output was generated
tho. but im sure its more then 5 minutes at least given that i have
Thanks for reporting this. This bug report isn't very useful because it doesn't
describe the bug well.
There is a template for a good reason. You don't tell us the hardware you use
or the exact software version. We don't even know if you run the latest
itos version: 4.2008.30-2
as for hardware, its a N800.
and here is some data that i gathered while checking to see if it was a
different, already reported bug.
lr-x------ 1 user users 64 Aug 18 21:43 0 -> /dev/null
l-wx------ 1 user users 64 Aug 18 21:43 1 -> /dev/null
lrwx------ 1 user users 64 Aug 18 21:43 10 ->
lrwx------ 1 user users 64 Aug 18 21:43 11 ->
lrwx------ 1 user users 64 Aug 18 21:43 12 ->
lrwx------ 1 user users 64 Aug 18 21:43 13 -> socket:
l-wx------ 1 user users 64 Aug 18 21:43 2 -> /dev/null
lrwx------ 1 user users 64 Aug 18 21:43 3 -> socket:
lr-x------ 1 user users 64 Aug 18 21:43 4 -> pipe:
l-wx------ 1 user users 64 Aug 18 21:43 5 -> pipe:
lrwx------ 1 user users 64 Aug 18 21:43 6 -> socket:
lrwx------ 1 user users 64 Aug 18 21:43 7 -> socket:
lrwx------ 1 user users 64 Aug 18 21:43 8 -> socket:
lrwx------ 1 user users 64 Aug 18 21:43 9 ->
i masked out the accounts dir-names.
modest is set up with two pop3 accounts set to download only headers.
and here is gdb output from the list threads command.
7 Thread 1118295184 (LWP 2416) 0x40bc6334 in pthread_cond_wait@@GLIBC_2.4 ()
6 Thread 1126769808 (LWP 2417) 0x40bc6334 in pthread_cond_wait@@GLIBC_2.4 ()
5 Thread 1136653456 (LWP 2418) 0x40bc6334 in pthread_cond_wait@@GLIBC_2.4 ()
4 Thread 1145042064 (LWP 2419) 0x40bc6334 in pthread_cond_wait@@GLIBC_2.4 ()
3 Thread 1153430672 (LWP 2420) 0x40bc6334 in pthread_cond_wait@@GLIBC_2.4 ()
2 Thread 1161819280 (LWP 2421) 0x40bc6334 in pthread_cond_wait@@GLIBC_2.4 ()
1 Thread 1073857008 (LWP 2413) 0x4011cd14 in poll () from /lib/libc.so.6
i also have a stack trace from a forced core dump, but i suspect it probably
not be useful.
#0 0x4011cd14 in poll () from /lib/libc.so.6
#1 0x40b4bf54 in ?? () from /usr/lib/libglib-2.0.so.0
(In reply to comment #6)
> i also have a stack trace from a forced core dump, but i suspect it probably
> not be useful.
> #0 0x4011cd14 in poll () from /lib/libc.so.6
> #1 0x40b4bf54 in ?? () from /usr/lib/libglib-2.0.so.0
Both gdb traces are very generic and not helpful.
Do you have the package sp-rich-core installed?
It's available from the tools repository and creates a "core-dumps"
directory to the memory card with at least few megabytes of free space. You can
get core dumps also without the rich-core package, but they are much less
i have it installed, but im somewhat worried about what kind of personal data
that dump may hold...
> i have it installed, but im somewhat worried about what kind of personal data
> that dump may hold...
In that case it's better to install debug symbols at least for things showing
in the backtrace (libc and glib, I think you can get them from the SDK repo)
and use Gdb to get backtraces you can paste here. It's more work though.
i could have sworn i tried that before doing the backtrace i posted the result
but i think i have figured out what the problem is now.
i had some issues with the wan/internet connection of my home network, and
while trying to get it working i discovered that when modest is sitting in ram,
it gave error messages as if it was set to check mails automatically.
and yes, i looked at its settings and it had that turned off.
so it may seem that modest is simply not honoring its automatic mail check
I'd like to add a comment that I'm not sure is correct here but I didn't want
to create a new bug. I'm running the latest diablo and did use modest for
about a week or two, however I've stopped using it now, deleted all of the
accounts, and turned off the auto checking feature within modest. The problem
is that modest still wants to load into memory and do something. I have know
idea what, but I have even deleted the ~/.modest directory and 5 minutes later
modest is loaded and the directory is recreated. This doesn't seem right to
me. I even kill the process and it comes back.
im starting to suspect that modest gets this issue if a manual check is
initiated while the connection is down.
its not a sure thing except i hhave yet to see it happen if i bring the
connection up manually first.
(In reply to comment #12)
> im starting to suspect that modest gets this issue if a manual check is
> initiated while the connection is down.
Any confirmations on this?
it seems to only show up when im not actively looking at the issue.
that is, i cant find any way to provoke it into happening. it just shows up
ever so often in normal use...
ok, i may have found the way to provoke the issue.
basically, have the tablet not connected to wifi.
start modest, then hit the refresh button in the corner.
when the wifi icon starts to blink (meaning its setting up a connection), tap
the refresh button again.
now if one close down modest, it should still show up in top, load-applet or
cute, there may be more then one thing going on here.
i just fould that modest do no respect that i have turned automated mail checks
off, and it results in the same symptom, modest staying in ram with no ui open.
spotted this by setting the check interval at 5 min.
if i then wait at least 5 min with wifi off and connect, modest shows up in top
and stays there even after the connection has closed.
I think this is a duplicate of bug 3953...
The rationale of the bug report is not correct. Modest does not stay in RAM in
order to check emails. We do that in order to speed up the time the device
needs to show the first window of the application. It's what it's called
The mechanism used to check email every X minutes does not need Modest to be
running. It's far more efficient. It's just a D-Bus message that wakes up the
application and performs the email check. After that the application will
If we keep it alive (currently for 30 minutes in Fremantle) it's only for
performance reasons as I have explained. And don't worry about RAM, there is
enough memory to have Modest (and some more applications) preloaded because the
benefit for th user is huge.
(In reply to comment #18)
> The rationale of the bug report is not correct. Modest does not stay in RAM in
> order to check emails.
Sergio, this bug report is for Diablo.
(And I think more appropriate resolution would be wontfix. Modest really is
running although user doesn't want it to run and has done everything he can
from the GUI to get it out.)
(In reply to comment #19)
> (In reply to comment #18)
> > The rationale of the bug report is not correct. Modest does not stay in RAM in
> > order to check emails.
> Sergio, this bug report is for Diablo.
Ups, I'm sorry I didn't realize. Anyway in Diablo Modest behaviour is the same.
What I suspect is that it could happen that Modest had some deadlock in the
code or something that prevented it from being properly closed.
> (And I think more appropriate resolution would be wontfix. Modest really is
> running although user doesn't want it to run and has done everything he can
> from the GUI to get it out.)
I agree. reopening...
Closing as wontfix