The Date and Time Indicator

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

Reported by Patrick Seher on 2011-04-28
38
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Indicator Date and Time
High
Charles Kerr
indicator-datetime (Ubuntu)
Undecided
Unassigned

Bug Description

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...

Tags: udp Edit Tag help

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) wrote :

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) wrote :

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

Changed in indicator-datetime:
importance: Undecided → High
status: New → Incomplete
David Baucum (maxolasersquad) wrote :

@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) wrote :

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) wrote :

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) wrote :

I notice that Valgrind log is from July.

Is anyone still seeing this behavior in >= 11.10?

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

David Baucum (maxolasersquad) wrote :

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

Changed in indicator-datetime:
status: Incomplete → New
Olli Ries (ories) on 2012-03-01
tags: added: udp
Changed in indicator-datetime:
milestone: none → 0.3.91
Ted Gould (ted) on 2012-03-08
Changed in indicator-datetime:
milestone: 0.3.91 → none
Charles Kerr (charlesk) on 2012-03-18
Changed in indicator-datetime:
assignee: nobody → Charles Kerr (charlesk)
status: New → In Progress
Charles Kerr (charlesk) wrote :

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.

Charles Kerr (charlesk) on 2012-03-20
Changed in indicator-datetime:
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in indicator-datetime (Ubuntu):
status: New → Fix Released
Charles Kerr (charlesk) on 2012-03-21
Changed in indicator-datetime:
status: Fix Committed → Fix Released
muzzamo (murray-waters) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers