GNOME Bugzilla – Bug 518524
E-D-S loops after gnome login (after a fresh reboot)
Last modified: 2010-01-09 20:52:30 UTC
Ubuntu original bug: https://bugs.launchpad.net/ubuntu/+source/evolution-data-server/+bug/151536 This one has been bothering me for a while now. Users report that, after rebooting the system and logging in Gnome, CPU utilisation was steady at 100%. Looking aroung, they see E-D-S eating up all CPU. Since the original report, we have been trying to get a nice stacktrace and additional data. A query I put to #evolution had a suggestion of network issues (specifically the network not being yet available after a fresh reboot and login); I have been unable to verify it. Finally, yesterday we were able to get a nice bt & a strace output. From the bt and the strace I have the feeling that this is very early in e-d-s init, and that poll() is returning very fast with timeouts. But, then, I am not a glib programmer, and I am not sure what this means, if anything at all. So... for you, folks. I will attach the bt and strace.
Created attachment 105886 [details] gdb output of such a loop
strace output is available at http://launchpadlibrarian.net/12175013/strace-eds.log
Given the number of hits we are getting (and the fact that, when this happens, the system gets sort of slow), is there any chances of having this looked at before 2.22?
chatted with mchra on #evolution. We still do not know what might be causing the loop, so we will ask the reporters to get a backtrace of both e-d-s and evolution-alarm-notify. Hum. Just in case, I will also ask for an 'ifconfig -a'.
Bumping version to a stable release.
backtraces (lots of them) are available on the ubuntu bug (https://bugs.launchpad.net/ubuntu/+source/evolution-data-server/+bug/151536). More and more Ubuntu users are joining in a "me too"... help is appreciated.
Whatever causes it... when evolution-alarm-notify is killed, then e-d-s stops looping. This sounds like a resource contention issue, driven by e-a-n. We should have a e-a-n backtrace in a few. I still find it weird that nobody else has experienced it except on Ubuntu hardy.
bt for e-a-n. Seems to be simply waiting
+ Trace 195130
further tests downstream show that killing e-a-n also causes e-d-s to die.
i have run into this issue several times but haven't found a pattern so far. top shows e-a-n eating all of my cpu and evolution never finishes to display my folders. this goes on for minutes until processes die.
Thread #3 seems to be in an infinite loop inside
+ Trace 196301
I couldn't "step" any of the other threads because they're all blocked in a syscall (poll). I repeatedly attached/detached from e-d-s and only got this behavior (thread #3 infinitely looping, the other 3 threads blocked). I've run oprofile on my system and this is the (relevant) output: $ opreport --symbols --image-path=/lib/modules/2.6.24-16-generic/ 6759333 48.9573 libglib-2.0.so.0.1600.3 libglib-2.0.so.0.1600.3 g_hash_table_lookup 5424338 39.2880 libglib-2.0.so.0.1600.3 evolution-data-server-2.22 g_hash_table_lookup
I see no (relevant) update on the downstream Ubuntu bug since 2008-04-13, neither any duplicates here for more than 18 months. What is the actual state of this, please?
I simply assume that this is OBSOLETE by now. If this still occurs, please reopen.