GNOME Bugzilla – Bug 738545
Busy loop under task_thread_cancelled()
Last modified: 2018-02-06 17:00:55 UTC
Created attachment 288543 [details] the backtrace from gdb with command `bt full` I am using GNOME 3.14 with Evolution 3.12.6. After logging in evolution-calendar-factory runs at 100% CPU usage (one core/thread) and slowly aquires more memory. This happens most if not every time I log in. Evolution and california are running fine without noticeable problems. I can stop (pause) the process which makes calendars unavailable in california and evolution. Whenever I terminate the process it will be started again. Running evolution-calendar-factory with debug output enabled as specified in https://wiki.gnome.org/Apps/Evolution/Debugging didn't help much, there was only one single line logged: Bus name 'org.gnome.evolution.dataserver.Calendar4' acquired. I attached a backtrace generated by gdb. If you need more info just tell me what to do.
Same problem here, also very similar reports on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755981 . Very annoying bug, renders evolution completely useless.
According to downstream bug reports https://bugzilla.redhat.com/show_bug.cgi?id=1148247 and https://bugzilla.redhat.com/show_bug.cgi?id=1151665 this is NM-related. It seems like this has getting worse. Now this bug renders evolution's calendar view completely useless, reminders don't work at all, the gnome-shell calendar view does not display any events and california is barely usable because it takes so long.
(In reply to comment #2) > It seems like this has getting worse. Now this bug renders evolution's calendar > view completely useless, reminders don't work at all, the gnome-shell calendar > view does not display any events and california is barely usable because it > takes so long. Makes sense, when the "server" (evolution-calendar-factory) is busy, it influences each client connecting to it.
Philip, is it possible your changes around task_thread_cancelled() from bug #736806 cause the issue here?
+ Trace 234304
I am pretty sure this is still just the NM bug. Only a limited number of task threads can be running at once, so if GNetworkMonitor signals are resulting in evo queuing a run-in-thread task, and the signals are being emitted at a ludicrous speed, then the queue of pending tasks would keep getting longer and longer, and so at some point, it becomes pretty likely that whenever you interrupt the process, it's going to be in the middle of re-sorting the queue, not because there's any bug in the sorting, but because the queue is huge. If it is the NM bug, then killing NM should make it go away. (Eventually... I don't know how long it would take evo to work through all its pending tasks.)
Just a side note, evolution is not running the tasks on its own, the tasks are run as part of a g_network_monitor_can_reach_async() call. The thing is that these are piled on each "network-changed" signal receive for each opened backend (calendar/book/...), thus if a network change invoked multiple "network-changed" signals, then it made the pile larger. The upcoming 3.12.8 version will have a workaround for this, to postpone these calls by several seconds, eventually group multiple "network-changed" signals into one g_network_monitor_can_reach_async() call.
I can confirm this issue as well. It doesn't happen all of the time, but it happens enough that it makes my machine too often unusable.
I haven't seen this bug in quite a long time, so I guess it is gone and has been fixed somewhere somehow. In case you still see this bug, please comment or reopen this bug report.