Indicator-datetime-service renders 100% CPU usage

[Darius Kulikauskas]

Binary package hint: indicator-datetime

On my laptop "indicator-datetime-service" occasionally make my CPU to use 100% of its resources. It does not happen every time I log in to Ubuntu, but when it happens, it stays hogging 100% of CPU until I kill the process. If it helps, I've noticed in "System Monitor" that there are two instances of "indicator-datetime-service" running, but only one of them is hogging recourses. So far I was unable to determine after what actions/events this bug pups up.

I'm using Ubuntu 11.04 64-bit.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: indicator-datetime 0.2.3-0ubuntu3
ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
Uname: Linux 2.6.38-8-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Sat Apr 30 15:27:58 2011
ExecutablePath: /usr/lib/indicator-datetime/indicator-datetime-service
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
SourcePackage: indicator-datetime
UpgradeStatus: Upgraded to natty on 2011-04-28 (1 days ago)

[jorge (xxopxe)]

See this too. Ubuntu 11.04 32 bits, updated from 10.10.

The process with 100% CPU was the oldest (smaller PID), after killing it everything seems back to normal, with the remaining indicator working ok.

[Sebastien Bacher (seb128)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please try to obtain a backtrace following the instructions at http://wiki.ubuntu.com/DebuggingProgramCrash and upload the backtrace (as an attachment) to the bug report. This will greatly help us in tracking down your problem.

[Christian Holschuh (chrisch-holli)]

I see this bug too on Ubuntu 11.04 in Classic mode. The first time realizing this bug was after installing the "weather indicator" from http://ppa.launchpad.net/weather-indicator-team/ppa/ubuntu repo.

[Darius Kulikauskas (dkulikauskas)]

Sorry, Sebastien Bacher, but the bug have not occured to me since I reported it, so I have not had a chance to make a backtrace.

However, I, like Christian Holschuh, also have indicator-weather installed. It might be related.

[Tanker Bob (tankerbob)]

I see this bug on Ubuntu 11.04 in Classic mode immediately after boot up as well. I'm not using the Gnome panels, but deleted those in favor of the AWN dock. I do have weather-indicator installed on the system and I cannot get it to not load with AWN, but I exit it immediately upon boot up completion. I uninstalled the gnome weather indicator, but it doesn't make a difference. Killing the process resolves the 100% CPU usage. This just started a few days ago.

[Tanker Bob (tankerbob)]

OK, after uninstalling the Gnome weather indicator and restarting, none of my CPUs pegs at 100%. It indeed looks like indicator-weather is related to the issue, though that's counter-intuitive with indicator-datetime. Since I'm using AWN and have deleted the standard Gnome panels in 11.04, indicator-datetime should not even load.

[Romano Giannetti (romano-giannetti)]

Happened to me. My guess is the wild e-calendar-fact(ory, I suppose) which make dbus and the indicator applet spin like crazy. As you can see in the attached screenshot, the indicator-datetime applet do not show anything when clicking...

[Launchpad Janitor (janitor)]

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

[Jelmer Vernooij (jelmer)]

I can reproduce this as well - and I also see fairly high CPU usage from dbus-daemon when this happens, similar to Romano.

[Jelmer Vernooij (jelmer)]

This is with the current version of indicator-datetime on Oneiric.

I'll try to grab a traceback next time this happens.

[Javier Jardón (jjardon)]

@Jelmer: what indicators have you installed?

[Martin Pitt (pitti)]

I don't have i-weather installed and get this, too, so it seems unrelated to weather. When this happens, dbus-daemon is also spinning at 100% CPU. It seems indicator-datetime is stuck in a tight loop and sends a million d-bus calls to evolution-data-server. Apparenlty it fails to check the d-bus call return code? It should wait with a retrying for a second or so, instead of immediately trying again.

[Ted Gould (ted)]

I had it happen just now and I grabbed the process with GDB and stole a backtrace. Not sure if this is telling, but I thought I'd safe it here :-)

(gdb) bt
#0 0x00007fe4539118bd in nanosleep () at ../sysdeps/unix/syscall-template.S:82
#1 0x00007fe453b8cd32 in g_usleep (microseconds=<optimized out>)
    at /build/buildd/glib2.0-2.29.18/./glib/gtimer.c:253
#2 0x00007fe454d68152 in ?? () from /usr/lib/libedataserver-1.2.so.15
#3 0x00007fe454d6b978 in e_gdbus_proxy_call_sync_boolean__void ()
   from /usr/lib/libedataserver-1.2.so.15
#4 0x00007fe455adfefc in ?? () from /usr/lib/libecal-1.2.so.10
#5 0x00007fe455ae022e in ?? () from /usr/lib/libecal-1.2.so.10
#6 0x00007fe453b63e5d in g_main_dispatch (context=0x7fe444001f40)
    at /build/buildd/glib2.0-2.29.18/./glib/gmain.c:2442
#7 g_main_context_dispatch (context=0x7fe444001f40)
    at /build/buildd/glib2.0-2.29.18/./glib/gmain.c:3011
#8 0x00007fe453b64658 in g_main_context_iterate (context=0x7fe444001f40,
    block=<optimized out>, dispatch=1, self=<optimized out>)
    at /build/buildd/glib2.0-2.29.18/./glib/gmain.c:3089
#9 0x00007fe453b64829 in g_main_context_iteration (context=0x7fe444001f40,
    may_block=0) at /build/buildd/glib2.0-2.29.18/./glib/gmain.c:3152
#10 0x00007fe454d6815b in ?? () from /usr/lib/libedataserver-1.2.so.15
#11 0x00007fe454d6b978 in e_gdbus_proxy_call_sync_boolean__void ()
   from /usr/lib/libedataserver-1.2.so.15
#12 0x00007fe455adfefc in ?? () from /usr/lib/libecal-1.2.so.10
---Type <return> to continue, or q <return> to quit---
#13 0x00007fe455ae022e in ?? () from /usr/lib/libecal-1.2.so.10
#14 0x00007fe453b63e5d in g_main_dispatch (context=0x7fe444001f40)
    at /build/buildd/glib2.0-2.29.18/./glib/gmain.c:2442
#15 g_main_context_dispatch (context=0x7fe444001f40)
    at /build/buildd/glib2.0-2.29.18/./glib/gmain.c:3011
#16 0x00007fe453b64658 in g_main_context_iterate (context=0x7fe444001f40,
    block=<optimized out>, dispatch=1, self=<optimized out>)
    at /build/buildd/glib2.0-2.29.18/./glib/gmain.c:3089
#17 0x00007fe453b64829 in g_main_context_iteration (context=0x7fe444001f40,
    may_block=0) at /build/buildd/glib2.0-2.29.18/./glib/gmain.c:3152
#18 0x00007fe454d6815b in ?? () from /usr/lib/libedataserver-1.2.so.15
#19 0x00007fe454d6b978 in e_gdbus_proxy_call_sync_boolean__void ()
   from /usr/lib/libedataserver-1.2.so.15
#20 0x00007fe455adfefc in ?? () from /usr/lib/libecal-1.2.so.10
#21 0x00007fe455ae022e in ?? () from /usr/lib/libecal-1.2.so.10
#22 0x00007fe453b63e5d in g_main_dispatch (context=0x7fe444001f40)
    at /build/buildd/glib2.0-2.29.18/./glib/gmain.c:2442
#23 g_main_context_dispatch (context=0x7fe444001f40)
    at /build/buildd/glib2.0-2.29.18/./glib/gmain.c:3011
#24 0x00007fe453b64658 in g_main_context_iterate (context=0x7fe444001f40,
    block=<optimized out>, dispatch=1, self=<optimized out>)
---Type <return> to continue, or q <return> to quit---
    at /build/buildd/glib2.0-2.29.18/./glib/gmain.c:3089
#25 0x00007fe453b64829 in g_main_context_iteration (context=0x7fe444001f40,
    may_block=0) at /build/buildd/glib2.0-2.29.18/./glib/gmain.c:3152
#26 0x00007fe454d6815b in ?? () from /usr/lib/libedataserver-1.2.so.15
#27 0x00007f...

[Michael Flaig (mflaig)]

This problem is happening quite often so should be reproduce able.
I think Evolution calendar has something to do with the load. However evolution needs not to be running. EDS would be enough.
Also I believe it to be related to dbus because I see my 2 cpu cores burned by 1 indicator-datetime process on one cpu and dbus-daemon on the other core.

[Antti Kaijanmäki (kaijanmaki)]

If someone happens to stumble upon this bug on a live system, please try to provide core dump with gdb:
(gdb) generate-core-file

That way I can debug the problem on my end even though there would be no debug symbols available on your end (like in the backtrace Ted provided).

Thanks!

[Timo Aaltonen (tjaalton)]

the corefile is 87MB, I've put it here:

http://koti.kapsi.fi/~tjaalton/tmp

it'll take ~15min to upload though..

[Antti Kaijanmäki (kaijanmaki)]

Thank you Timo!

[Antti Kaijanmäki (kaijanmaki)]

Unfortunately the core dump TImo provided was from dbus-daemon. Not much happening there :(

I've tried to reproduce, but no luck yet.

If someone sees the bug happening, please, provide a core dump of the indicator-datetime-service process. Thanks!

[Jo-Erlend Schinstad (joerlend.schinstad-deactivatedaccount)]

This happens to me often in 11.10. I've never experienced it in 11.04. I have no idea how to reproduce it. It just happens when I leave my computer running for some time.

[David Barth (dbarth)]

@Antti: I've had this bug as well. It was essentially EDS configured with an extra gmail account trying to sync/import my online calendar; except that the authenication was not working because i had removed the password from the keyring, or the keyring was not unlocked because I had cancelled the annoying popup dialogs.

[aq1018 (aq1018)]

I got the core dump for indicator-datetime.

http://dl.dropbox.com/u/7022019/core.1815

Size is about 110MB.

I'm using Ubuntu 11.10 beta and got this core dump when both indicator-datetime and dbus-daemon are taking out most of my cup cycles.

[James Hunt (jamesodhunt)]

I get this bug constantly. Clicking the indicator and selecting "Refresh" seems to often trigger the problem.

Doing a quick ltrace when it's in "hog mode" shows:

e_cal_get_source(0x92a14a0, 0xb7843b31, 5, 0xb78575ac, 0x92a14a0) = 0xb2e013b0
e_source_get_duped_property(0xb2e013b0, 0x8050165, 5, 0xb78575ac, 0x92a14a0) = 0
e_passwords_get_password(0x805015c, 0xb2abc098, 5, 0xb78575ac, 0x92a14a0) = 0
g_free(0, 0xb2abc098, 5, 0xb78575ac, 0x92a14a0) = 0
e_cal_get_source(0x92a1638, 0xb7843b31, 5, 0xb78575ac, 0x92a1638) = 0x92be900
e_source_get_duped_property(0x92be900, 0x8050165, 5, 0xb78575ac, 0x92a1638) = 0
e_passwords_get_password(0x805015c, 0xb2abc9d0, 5, 0xb78575ac, 0x92a1638) = 0
g_free(0, 0xb2abc9d0, 5, 0xb78575ac, 0x92a1638) = 0
e_cal_get_source(0x9241a68, 0xb7843b31, 5, 0xb78575ac, 0x9241a68) = 0xb2e00fc0
e_source_get_duped_property(0xb2e00fc0, 0x8050165, 5, 0xb78575ac, 0x9241a68) = 0
e_passwords_get_password(0x805015c, 0xb2abd308, 5, 0xb78575ac, 0x9241a68) = 0
g_free(0, 0xb2abd308, 5, 0xb78575ac, 0x9241a68) = 0

e_passwords_get_password() is an evolution call. Since I don't use evolution, I decided to kill all evolution processes. This seemed to resolve the problem:

  killall -9 e-calendar-factory e-addressbook-factory

Although these processes are respawned when e_passwords_get_password() is subsequently called, the indicator doesn't hog my CPU.

[Sebastien Bacher (seb128)]

the recent comment is interesting, thanks James, random idea about the issue:

could it happen if you have a calendar that requires authentification but is not unlocked? in natty the indicator was segfaulting on those but made to ignore them because there was an issue with the ui, maybe it's trying to get the password prompt there?

[Antti Kaijanmäki (kaijanmaki)]

aq1018, James: Thanks for the info!

Sebastian: I will check that.

[Antti Kaijanmäki (kaijanmaki)]

Now, the fix should prevent dbus-daemon to get to 100% CPU, but there's still excess traffic caused by e-calendar-factory. I will continue on investigating that.

[Launchpad Janitor (janitor)]

This bug was fixed in the package indicator-datetime - 0.3.0-0ubuntu1

---------------
indicator-datetime (0.3.0-0ubuntu1) oneiric; urgency=low

  [ Ken VanDine ]
  * debian/control
    - Added recommends for e-d-s

  [ Ted Gould ]
  * New upstream release.
    * Fix corrupt environment when LANGUAGE not set (LP: #861123)
    * Measure string size with GLib (LP: #730476)
    * Free ECals when they have errors (LP: #774071)
    * Fix untranslated string (LP: #853130)
 -- Ted Gould <email address hidden> Thu, 29 Sep 2011 15:39:41 -0500

[Håvar (havar)]

This bug still haunts natty, which still has indicator-datetime 0.2.3. Is there any hope for the fixed package finding its way into natty-updates?

[P Cantwall (p-cantwell)]

E-calendar-factory will peruse my calendar data periodically, possibly to determine if I have to be reminded of something. However, I keep a very large amount of historical data in my calendar. Because of this, e-calendar-factory takes a very long time to search, all the while taking 100% of one CPU. I notice the slowdown on my dual-core CPU and maybe it will be less noticeable with more cores. Evolution is aware of this problem, too, but their fix is to archive old data from my calendar. My fix would be to index the database and only search for future dates, not old history.

In the meantime, is there any way in Ubuntu to lower E-calendar-factory priority manually, like Windows can? I don't mind if it takes 90-minutes at 20% CPU, instead of 15-minutes at 100%. Maybe Evolution's maintainers can give my background processes more chance to run during its queries.

[P Cantwall (p-cantwell)]

BTW, 11.10 and Evolution 3.2.1, but I had it in 10.10 & 11.04 and Evolution 2.whatever.

[P Cantwall (p-cantwell)]

That's pretty good: it's down to 98% now. Ubuntu 11.10 & Evo 3.2.1.

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

24579 pete 20 0 769m 475m 6760 S 98 23.7 0:33.85 e-calendar-fact
23083 pete 20 0 545m 89m 36m R 4 4.4 0:51.38 chromium-browse
 1086 root 20 0 167m 46m 22m S 2 2.3 0:52.60 Xorg
21938 pete 20 0 27928 3528 824 S 2 0.2 0:27.03 dbus-daemon
22246 pete 20 0 438m 44m 28m S 2 2.2 0:13.67 unity-2d-panel
22247 pete 20 0 578m 62m 35m S 2 3.1 0:04.34 unity-2d-launch
22327 pete 20 0 326m 25m 10m S 2 1.3 0:31.04 unity-panel-ser
22334 pete 20 0 294m 9032 7128 R 2 0.4 0:07.18 indicator-datet
    1 root 20 0 24160 1920 1264 S 0 0.1 0:00.58 init

[Charles Kerr (charlesk)]

P Cantwall, sounds great -- now we only need to do this 98 more times and things will be perfect! ;)

In the OP's description, it was indicator-datetime-service that was pegging to 100%. In your snapshot in comment #32 it's e-calendar-factory going crazy, so it's possible that you're encountering an unrelated issue. Could you get a gdb backtrace or ltrace of e-calendar-factory when the high load occurs?

[Marcos Roriz (marcosrorizinf)]

Hi guys, I still have this bug (I'm running natty). Any chance that the fix will land here???

[indium (indium)]

This bug is still not solved for me today. I'm on a macbook pro 6,2 with an uptotdate 11.10 ubuntu.

indicator-datetime 0.3.1-0ubuntu1.1

I did the following:

$ gdb program 27962 (where 27962 is the PID of indicator-datetime)

This stops the application from eating all my CPU! Does that say something?

the core file is 'core.27962' and is huge, so I've put it on:
http://homepage.tudelft.nl/8t03d/dump/core.27962.bin

Any help would be appreciated, because I cannot use the interface anymore for months now!

[indium (indium)]

Does anyone still work on this? I have tried the ubuntu standard WM again (unity), but still I have 100% CPU consumed by indicator-date-time and it is eating memory (was 1.1% after restarting the computer, now 11.1% after ten minutes).

[Steven Haber (sthaber)]

Hit the same issue today on 12.4. I was unable to unlock my desktop until I killed indicator-datetime-service from a virtual terminal.

[indium (indium)]

The problem for me is gone after installing 12.04.

On Thu, May 03, 2012 at 06:03:12PM -0000, RawwrBag wrote:
> Hit the same issue today on 12.4. I was unable to unlock my desktop
> until I killed indicator-datetime-service from a virtual terminal.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (884701).
> https://bugs.launchpad.net/bugs/774071
>
> Title:
> Indicator-datetime-service renders 100% CPU usage
>
> Status in The Date and Time Indicator:
> Fix Released
> Status in Unity Foundations:
> Fix Released
> Status in “indicator-datetime” package in Ubuntu:
> Fix Released
>
> Bug description:
> Binary package hint: indicator-datetime
>
> On my laptop "indicator-datetime-service" occasionally make my CPU to
> use 100% of its resources. It does not happen every time I log in to
> Ubuntu, but when it happens, it stays hogging 100% of CPU until I kill
> the process. If it helps, I've noticed in "System Monitor" that there
> are two instances of "indicator-datetime-service" running, but only
> one of them is hogging recourses. So far I was unable to determine
> after what actions/events this bug pups up.
>
> I'm using Ubuntu 11.04 64-bit.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 11.04
> Package: indicator-datetime 0.2.3-0ubuntu3
> ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
> Uname: Linux 2.6.38-8-generic x86_64
> NonfreeKernelModules: nvidia
> Architecture: amd64
> Date: Sat Apr 30 15:27:58 2011
> ExecutablePath: /usr/lib/indicator-datetime/indicator-datetime-service
> InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
> SourcePackage: indicator-datetime
> UpgradeStatus: Upgraded to natty on 2011-04-28 (1 days ago)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/indicator-datetime/+bug/774071/+subscriptions

[Mike Morris (mike-musicplace)]

I am now having this problem too, after just upgrading to 12.04 from 11.10. I have noticed 2 things that may be relevant:

(1) It only occurs when booting with lightdm as display manager. I'm a KDE user, and when I switched back to kdm, the problem went away. I've switched between lightdm and kdm a handful of times, and so far the problem occurs 100% of the time when running lightdm and never under kdm.

(2) Sounds like people see at least one other process going hayway besides indicator-datetime; for me it is geocode-<something>... I forget exactly. Also the dbus daemon... those 3 are way out of line under lightdm.

Also... most of the above reference only CPU utilization, but on my system the memory usage grows steadily, eventually consuming all physical memory and all swap at which point the system becomes completely unusable.

[jherazob (jherazob)]

I suspect it's linked to geoclue.

Just now i killed geclue-master, which remained open and taking CPU after i killed indicator-datetime, and system load and CPU usage went drastically down. And before that, the locations on the indicator flashed in and out of existence (flashing between being and not being shown, several times a second).

This, plus geoclue-plazes segfaulting on me many times a day leads me to suspect the fault is there, but what makes me doubt is that this happens even if i turn off showing the date in other locations.

Either way, this could be the missing clue on getting this bug.

[jherazob (jherazob)]

Quick demonstration of the effect i mentioned is attached, as a recordmydesktop ogv video capture

Turning off alternate locations will not solve the issue, it'll still be there open and taking up all of the CPU. Also, the involved processes will only occasionally stay dead, they typically respawn, taking again all of the CPU.

[Arne Caspari (arne-datafloater)]

I have the same issue like jherazob. Maybe this is a new issue compared to the 100% cpu issue discussed above?

[FranJPR (fjperezor)]

After the upgrade to Ubuntu 12.10, I have to kill indicator-datetime-service everytime at startup to stop cpu usage and constant access to hdd and turn the system usable.

[Jacek Ławrynowicz (daeronpl)]

I experienced the similar problem on 12.10 and 13.04
indicator-datetime-service together with gnome-settings-daemon - process kept eating RAM and used 100% CPU. Problem turned out to be some corrupted cache files in ~/.cache/ . Upon deleting them, problem stopped.

It first began then I used Raring (13.04). I migrated to Quantal (12.10) without changing my home directory. After several reboots and apt-get upgrade problem started occuring again.

Anyone experiencing this I suggest wiping their ~/.cache folder.

[Brad Dunn (subscrips)]

I am having this same problem also. I have to restart to make it go away. This happens every once in awhile. I did not notice any other processes using much cpu. It affects 1 of 2 cores. I am using LinuxMint 14.1 and will post it to that launchpad, but wanted to inform this group as LM is an Ubuntu distribution. I do not have any calendar syncing on this machine or any thing really running on it as I use it as a backup server. The only software updates that I have done relating to time was to install ntp and use over ntpdate.

[Arthur Zalevsky (aozalevsky)]

It's a great problem for me, because i've got multi-user machines. So it's about 3 or 5 datetime-indicator-service processes on every machine and each one consumes whole core.

[Stefan Tauner (stefanct)]

Don't expect anybody to read a bug report that has a "fix released" state since 2011. Either change the state of this bug report or file a new one (I think the latter would be better actually, but i did not read the whole thread in detail).

[Wiktor Wandachowicz (siryes)]

Since I upgraded to 12.04 recently I've started to notice this problem. Namely, indicator-datetime-service was still running at 100% CPU, and was quickly restarted (with just highter PID) after killing its process.

However, I was puzzled why at the same time some geoclue- related service also worked? I've found that indicator-datetime package indeed has a dependency upon: geoclue-yahoo | geoclue-provider. Then I have started to suspect that the real problem somehow comes from issue with geoclue - and I was right (in my case).

MY SOLUTION:
I have used aptitude and marked geoclue-yahoo to be uninstalled, then I solved the now missing dependency by marking geoclue-ubuntu-geoip to be installed. After installation geoclue provider was essentially switched. Now I have no more 100% CPU problem, but a usable system instead.

Probably I could have used any other package that is listed in geoclue-provider virtual package, and there are many.
Go figure:
* geoclue-ubuntu-geoip 0.0.2-0ubuntu6
* geoclue-gypsy 0.12.0-1ubuntu4
* geoclue-gsmloc 0.12.0-1ubuntu4
* geoclue-gpsd 0.12.0-1ubuntu4
* geoclue-yahoo 0.12.0-1ubuntu12
* geoclue-skyhook 0.12.0-1ubuntu12
* geoclue-plazes 0.12.0-1ubuntu12
* geoclue-manual 0.12.0-1ubuntu12
* geoclue-localnet 0.12.0-1ubuntu12
* geoclue-hostip 0.12.0-1ubuntu12
* geoclue-geonames 0.12.0-1ubuntu12

Hope this helps.

[Jean-Pol Landrain (jplandrain)]

Seeing this after upgrade from 16.04 to 16.10

[Anders Hall (a.hall)]

Seeing this on 17.10 as well. Battery indicator says ("estimating...., 100%) and indicator-datetime-service uses between 2.4 GiB and (mostly) ~14.5 GiB RAM. CPU usage stays at 25% all the time. The indicator-datetime-service crashes after reaching all available RAM, then restarts with new PID.

I reported, with debug info, about the relevant PID in Bug #1731939 (apport-collect didnt work during the bug event).

[Anders Hall (a.hall)]

Sorry, wrote incorrect. Reported for 17.04 LTS above.

Work-around (I cant upgrade to 17.10 due to KVM bug): Turn of the t

[Anders Hall (a.hall)]

(#51 was a mistake)

Sorry, wrote incorrect. Reported for 17.04 LTS above.

Work-around (I cant upgrade to 17.10 due to KVM bug): Turn of the "Show a clock in the menu bar" in System Settings for Time & Date. Worked after cold reboot.

[Anders Hall (a.hall)]

Last work-around didn't stick. Don't think this bug or #1731939 is about indicator-datetime-service. It seems to be evolution calendar that is the problem. See comment below:

https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/1731939/comments/4

Will test 17.10 now.

[Anders Hall (a.hall)]

The problem went away in 17.10. Cheers.

[Rüdiger Kupper (ruediger.kupper)]

No. I see it in 17.10 as of today (2018-01-09). I cannot log intro Unity because of this bug. Right after login, indicator-datetime-service" eats all of my CPU, breaks, starts again, eats all of my CPU, breaks, starts again, eats all of my CPU, breaks, starts again, eats all of my CPU, breaks, starts again, eats all of my CPU, breaks, starts again, eats all of my CPU, breaks, starts again, eats all of my CPU, breaks, starts again, eats all of my CPU, breaks, starts again, eats all of my CPU, breaks, starts again, eats all of my CPU, breaks, starts again, eats all of my CPU, breaks, starts again, eats all of my CPU, breaks, starts again, eats all of my CPU, breaks, starts again, eats all of my CPU, breaks, starts again, eats all of my CPU, breaks, starts again, eats all of my CPU, breaks, starts again, eats all of my CPU, breaks, starts again, eats all of my CPU, breaks, starts again, eats all of my CPU, breaks, starts again, eats all of my CPU, breaks, starts again, eats all of my CPU, breaks, starts again, eats all of my CPU, breaks, starts again...

[Mister X (julian-erhard)]

This is still an issue in Ubuntu 20.04.

[Mister X (julian-erhard)]

Output generated with:
valgrind --tool=massif /usr/lib/x86_64-linux-gnu/indicator-datetime/indicator-datetime-service
Can be viewed with:
ms_print massif.out.8535 | less

Might be the following function be at fault?
unity::indicator::datetime::EdsEngine::Impl::fetch_detached_instances(_GObject*, _GAsyncResult*, void*) (in /usr/lib/x86_64-linux-gnu/indicator-datetim
e/indicator-datetime-service)

The very rapidly growing memory consumption (until it eats up all of the memory) and CPU usage only occurs when I have synced my Google calendar. Maybe it tries to fetch to many entries?
In particular, I suspect that the issue might have to do with calendar entries that are repeated infinitely often in Google calendar.

[Mister X (julian-erhard)]

The problem seems to be that one call to e_cal_client_get_objects_for_uid does not result in a callback when querying a uid with infinite entries. Probably ecal tries to fetch all of them?

Is there a different ecal function that one could call? How is it done in Evolution or Gnome calendar, so that it does not eat up all the memory? Do they do a different call?

Or maybe e_cal_client_get_objects_for_uid() should not be called when it is known that it is an repeating event?

[gst (g-starck)]

I confirm the bad behavior on my side with google account enabled..

[ai_ja_nai (albertomassidda)]

I confirm too the bad behaviour with Google account. Worked around deactivating calendar sync.
This is a problem, anyway.