evolution-calendar-factory uses lots of memory

[Eric Broneer]

As filed under bug #1342123 (under Canonical System Image, i.e. for mobile installs) by several users, including desktop installs, evolution-calendar-factory (previsouly in 14.04) then evolution-calendar-factory-subprocess (in 16.04) run using several hundreds of megabytes of memory (~ 300 Mio in my case).
This might have to do with having lots of linked calendars (Google Agenda or other). Another user on my system has much fewer Google Agendas than me and her memory usage of evolution-calendar-factory-subprocess is less, but still close to 100 Mio.
There have been random crashes of the process, mostly directly upon login, always caused by addressing memory out of range.
There used to be a workaround by invoking the process a second time, which caused it to exit more or less gracefully. This is not the case anymore in 16.04.
Unfortunately, searching Google leads to the bug #1342123 which concerns "Canonical System Image", and several users have replied even though it does not only concern mobile installs, which is not immediately self-evident when you are not aware what "Canonical System Image" stands for…

[Sebastien Bacher (seb128)]

Thank you for your bug report, could you try to get a valgrind log showing the leak? is it linked to some specific calendar (can you repeat/try by disabling some accounts?)

[Eric Broneer (ledoc)]

Hi @seb128 ,
I have tried disabling my three online Google accounts and the subprocess disappears altogether. As soon as I re-enable one account with few Google Agenda items, it comes back with ~ 50 Mio. When I enable the main account that has a good many Google Agenda items, the subprocess starts to happily eat away at its 300+ Mio.
So the obvious workaround now is to disable GMail and Calendar synchronization in System parameters/Online accounts (see attached screenshot).
Concerning the putative memory leak (the subprocess does indeed eat away at more and more memory as time goes by), this would include compiling evolution-calendar-factory-subprocess with MemCheck, wouldn't it? I would need the compile options and other things I'm not very familiar with… :/

[Eric Broneer (ledoc)]

Temporary workaround for high memory usage of evolution-calendar-factory-subprocess

[Launchpad Janitor (janitor)]

[Expired for evolution-data-server (Ubuntu) because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for indicator-datetime (Ubuntu) because there has been no activity for 60 days.]

[BronsonMathews (bronsonmathews)]

still happening, 3x process using 40mb+ ram each!

[BronsonMathews (bronsonmathews)]

on 16.04 btw

[Omar Elazhary (omazhary)]

I can confirm it still exists on 16.04. Any news regarding this?

[dronus (paul-geisler)]

Even large memory usage for 16.04 clean install with empty calendar and without any online accounts added.

[Khurshid Alam (khurshid-alam)]

This has been fixed for 3.20 in yakkety. Can anyone confirm. If so, It would be a SRU bug for backporting 3.20 to 16.04 would be nice.

[albflo (albflo)]

Still happens in 16.04.1 with Gnome 3.18, the evolution-calendar-factory-subprocess and evolution-source-registry process are the highest ranked in the system monitor, with 12% and 8% of CPU usage and a memory usage of around 100MB.

[TitanKing (titan-phpdevshell)]

Upgraded Ubuntu Gnome 16.04.2 to Gnome 3.20.4 with same issue. Except I get 4 running processes and I can find no way of disabling it. Its a bummer. I don't use calendar at all.

[TitanKing (titan-phpdevshell)]

Upgraded Ubuntu Gnome 16.04.2 to Gnome 3.20.4 with same issue. Except I get 4 running processes and I can find no way of disabling it. Its a bummer. I don't use calendar at all.

Here is what I did to disable these services;

sudo chmod -x /usr/lib/evolution/evolution-calendar-factory
sudo chmod -x /usr/lib/evolution/evolution-addressbook-factory
sudo chmod -x /usr/lib/evolution/evolution-source-registry

[Trent Nelson (trent-a-b-nelson)]

TitanKing,

I'd posted a bit less intrusive workaround at https://askubuntu.com/a/894387/653294.

[Iván Pérez (ivan.perez-keera.es)]

I can confirm that this problem exists in 18.04 and that disabling the linked Google account in Account Settings worked for me.

The chmod-based solution posted by titan-phpdevshell (#13) also worked, but I expect that to stop working as soon as I upgrade.