e-calendar-fact and indicator-datet consumes 2,6GB Memory

[Patrick Seher]

I did an upgrade from 10.10; x64
Since the Update these two processes uses 2,6 GB Memory:

 1684 patrick 20 0 1692m 1.1g 4620 R 28 28.1 18:49.24 e-calendar-fact
 1667 patrick 20 0 2082m 1.5g 5192 S 17 40.1 14:16.00 indicator-datet

i have this behavor after every startup. when i kill the both processes, the processes appears seconds later again (about 17MB and 6,8MB) - and everything is fine... i use an (big) caldav calendar with evolution...

[Patrick Seher (patrick-seher-it)]

today i had the same issue again (since the bug report everything works fine):

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1747 patrick 20 0 3644m 1.0g 2804 S 21 27.0 55:06.06 e-calendar-fact
1707 patrick 20 0 4746m 1.4g 3248 S 91 35.9 34:46.49 indicator-datet

[Johnathon (outdooricon)]

I'm seeing indicator-datetime-service consume 1.3GB of memory so far. I just shut down evolution without a chance to see what was happening with e-calendar but there definitely appears to be a memory leak. I'm using Exchange/MAPI integration in evolution, so it's syncing calendars with Exchange. It looks like there was a thread of others seeing the issue also at http://ubuntuforums.org/showthread.php?t=1684484

[Ted Gould (ted)]

Hmm, that's a lot of memory :-) If you could grab a profile with Valgrind that would be the biggest help in getting it fixed. Thanks!

https://wiki.ubuntu.com/Valgrind

[David Baucum (maxolasersquad)]

@ted: This backtrace was uploaded in duplicate bug 782468 by pd5rm (pedrum). He had the following to say about his upload:
Ok, so I replaced the /usr/lib/indicator-datetime/indicator-datetime-service with a bash script that calls binary through valgrind (probably what I should've done in the first place).

I see a lot of calendar fetching for repeat events in my evolution calendar source.

See attachment for log.

[David Baucum (maxolasersquad)]

A second backtrace was ran by him also wtih the following note:
Ok, so I replaced the /usr/lib/indicator-datetime/indicator-datetime-service with a bash script that calls binary through valgrind (probably what I should've done in the first place).

I see a lot of calendar fetching for repeat events in my evolution calendar source.

See attachment for log.

[Charles Kerr (charlesk)]

The high watermark of memory use in those valgrind logs is in the range of 4-7 MB, rather than GB:

==8152==
==8152== LEAK SUMMARY:
==8152== definitely lost: 74,985 bytes in 143 blocks
==8152== indirectly lost: 3,980 bytes in 201 blocks
==8152== possibly lost: 3,387,561 bytes in 30,183 blocks
==8152== still reachable: 4,282,719 bytes in 35,644 blocks
==8152== suppressed: 0 bytes in 0 blocks
==8152== Reachable blocks (those to which a pointer was found) are not shown.
==8152== To see them, rerun with: --leak-check=full --show-reachable=yes

I wonder where the rest of the 2.6 GB is coming from.

[Charles Kerr (charlesk)]

I notice that Valgrind log is from July.

Is anyone still seeing this behavior in >= 11.10?

[Patrick Seher (patrick-seher-it)]

yes, still the same issue. But it only happens when my pc run longer than 24h without a reboot.

[David Baucum (maxolasersquad)]

I'm definitely seeing this issue less, but it did happen earlier this week.

[Charles Kerr (charlesk)]

Okay, I've run indicator-datetime-session in valgrind over the weekend and have found several memory leaks related to appointments. I have a work-in-progress plugging these leaks at lp:~charlesk/indicator-datetime/lp-772340 and when I'm done with them I'll propose that for merging.

FWIW, without appointments enabled there was nearly no change in the footprint size.

[Launchpad Janitor (janitor)]

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

---------------
indicator-datetime (0.3.92-0ubuntu1) precise; urgency=low

  * New upstream release.
    * Fix several memory leaks (LP: #772340, LP: #957320)
 -- Charles Kerr <email address hidden> Wed, 21 Mar 2012 11:22:20 -0500

[muzzamo (murray-waters)]

I was experiencing this problem on 13.04 raring ringtail, running gnome-classic (didn't have ubuntu-desktop package installed).

Installing geoclue-examples and restarting seemed to fix the problem.