indicator-datetime-session severely leaks memory

Bug #951496 reported by Marcel Stimberg
This bug report is a duplicate of:  Bug #829967: indicator-datetime leaks memory. Edit Remove
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Indicator Date and Time
Invalid
High
Charles Kerr
geoclue (Ubuntu)
Fix Released
Undecided
Unassigned
indicator-datetime (Ubuntu)
Incomplete
Undecided
Unassigned

Bug Description

After the most recent update to 0.3.91-0ubuntu1, indicator-datetime-session's memory increases at a rate of ~5MB/s, rendering my system unusable in a couple of minutes. Any advice on how to debug this issue? The service is always respawned after I kill it, making it impossible to directly run it in a terminal -- is there a way to prevent that? The issue persists even if I switch off the date display in the indicator bar. If I do an strace to the running process, the following seems to be repeated in an infinite loop:
open("/usr/share/zoneinfo/Europe/Paris", O_RDONLY) = 14
fstat(14, {st_mode=S_IFREG|0644, st_size=2945, ...}) = 0
mmap(NULL, 2945, PROT_READ, MAP_PRIVATE, 14, 0) = 0x7fd1a6bd9000
close(14) = 0
munmap(0x7fd1a6bd9000, 2945) = 0
open("/usr/share/zoneinfo/UTC", O_RDONLY) = 14
fstat(14, {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
mmap(NULL, 118, PROT_READ, MAP_PRIVATE, 14, 0) = 0x7fd1a6bd9000
close(14) = 0
munmap(0x7fd1a6bd9000, 118) = 0
open("/usr/share/zoneinfo/Europe/Paris", O_RDONLY) = 14
fstat(14, {st_mode=S_IFREG|0644, st_size=2945, ...}) = 0
mmap(NULL, 2945, PROT_READ, MAP_PRIVATE, 14, 0) = 0x7fd1a6bd9000
close(14) = 0
munmap(0x7fd1a6bd9000, 2945) = 0
open("/usr/share/zoneinfo/America/Los_Angeles", O_RDONLY) = 15
fstat(15, {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0
mmap(NULL, 2819, PROT_READ, MAP_PRIVATE, 15, 0) = 0x7fd1a6bd9000
close(15) = 0
munmap(0x7fd1a6bd9000, 2819) = 0
poll([{fd=3, events=POLLIN}, {fd=10, events=POLLIN}, {fd=12, events=POLLIN}, {fd=11, events=POLLIN}], 4, 0) = 2 ([{fd=3, revents=POLLIN}, {fd=11, revents=POLLIN}])
read(3, "\1\0\0\0\0\0\0\0", 16) = 8
sendmsg(11, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\0\0\0\0000\r\4\0\225\0\0\0\1\1o\0(\0\0\0/org/fre"..., 168}, {"", 0}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 168
sendmsg(11, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\0\0\0\0001\r\4\0\233\0\0\0\1\1o\0(\0\0\0/org/fre"..., 176}, {"", 0}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 176
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
recvmsg(11, {msg_name(0)=NULL, msg_iov(1)=[{"l\4\1\1\35\0\0\0F\336b\1\247\0\0\0\1\1o\0(\0\0\0/org/fre"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 325
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
recvmsg(11, {msg_name(0)=NULL, msg_iov(1)=[{"l\3\1\1:\0\0\0I\336b\1w\0\0\0\6\1s\0\6\0\0\0:1.354\0\0"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 194
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
recvmsg(11, 0x7fff9e33d3d0, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
poll([{fd=3, events=POLLIN}, {fd=10, events=POLLIN}, {fd=12, events=POLLIN}, {fd=11, events=POLLIN}], 4, 0) = 1 ([{fd=3, revents=POLLIN}])
read(3, "\6\0\0\0\0\0\0\0", 16) = 8
poll([{fd=3, events=POLLIN}, {fd=10, events=POLLIN}, {fd=12, events=POLLIN}, {fd=11, events=POLLIN}], 4, 0) = 0 (Timeout)
read(3, 0x7fff9e33d5d0, 16) = -1 EAGAIN (Resource temporarily unavailable)
write(2, "\nIndicator-Datetime-WARNING **: "..., 117) = 117
poll([{fd=3, events=POLLIN}, {fd=10, events=POLLIN}, {fd=12, events=POLLIN}, {fd=11, events=POLLIN}], 4, 0) = 0 (Timeout)
read(3, 0x7fff9e33d5d0, 16) = -1 EAGAIN (Resource temporarily unavailable)
write(2, "\nIndicator-Datetime-WARNING **: "..., 72) = 72
sendmsg(11, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\0\0\0\0002\r\4\0\215\0\0\0\1\1o\0(\0\0\0/org/fre"..., 160}, {"", 0}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 160
write(8, "\1\0\0\0\0\0\0\0", 8) = 8
write(7, "\1\0\0\0\0\0\0\0", 8) = 8
futex(0x7fd1a000b780, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7fd1a000b2e0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x20e7e00, FUTEX_WAKE_PRIVATE, 1) = 1

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: indicator-datetime 0.3.91-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-18.28-generic 3.2.9
Uname: Linux 3.2.0-18-generic x86_64
ApportVersion: 1.94.1-0ubuntu2
Architecture: amd64
CheckboxSubmission: 476acdb7217a83354f628beaa5c14f06
CheckboxSystem: daed2f3d6643b4a84b4520a2427f8c2b
Date: Sat Mar 10 13:29:07 2012
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha amd64 (20100114)
ProcEnviron:
 TERM=xterm
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: indicator-datetime
UpgradeStatus: Upgraded to precise on 2012-01-20 (49 days ago)

Revision history for this message
Marcel Stimberg (marcelstimberg) wrote :
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for your bug report, how way to get info is to stop the unity-panel-service by attaching gdb to it, then restart the indicator-datetime-service from a command line with INDICATOR_ALLOW_NO_WATCHERS=1 and detach gdb

Changed in indicator-datetime:
assignee: nobody → charles (charlesk)
Revision history for this message
Marcel Stimberg (marcelstimberg) wrote :

Sebastien, thanks for your advice. This is the output I get on the commandline:

Indicator-Datetime-WARNING **: Address provider changed. Let's change

** WARNING **: Metadata for error domain "geoclue-error-quark" already registered

Indicator-Datetime-WARNING **: Address provider changed. Let's change

Indicator-Datetime-WARNING **: Unable to get Geoclue address: Geoclue master client has no usable Address providers

Indicator-Datetime-WARNING **: Address provider changed. Let's change

Indicator-Datetime-WARNING **: Unable to get Geoclue address: Geoclue master client has no usable Address providers

Indicator-Datetime-WARNING **: Address provider changed. Let's change

The last two lines are then repeated infinitely.

Revision history for this message
Sebastien Bacher (seb128) wrote :

do you have geoclue-ubuntu-geoip installed?

Revision history for this message
Marcel Stimberg (marcelstimberg) wrote :

I did not have geoclue-ubuntu-geoip installed and installing it (+ logging out and back in) indeed fixed the problem, indicator-datetime-service is back to a reasonable memory consumption which does not seem to grow over time. indicator-datetime-service's dependence on "geoclue-ubuntu-geoip | geoclue-provider" was apparently fulfilled by geoclue-examples... judging from its name and description, this package should possibly not claim "Provides: geoclue-provider".

Many thanks for the quick help!

Olli Ries (ories)
Changed in indicator-datetime:
importance: Undecided → High
Revision history for this message
Charles Kerr (charlesk) wrote :
Revision history for this message
Charles Kerr (charlesk) wrote :

I'm not sure what the proper launchpad-fu is here. This ticket could be marked as a duplicate of the leak ticket closed for datetime 0.3.92, but that would lose this separate issue wrt geoclue-examples. So I'm going to mark the Affects: datetime lines as invalid for this ticket and leave it to geoclue.

Marcel, thanks for reporting this.

Changed in indicator-datetime:
status: New → Invalid
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package geoclue - 0.12.0-1ubuntu12

---------------
geoclue (0.12.0-1ubuntu12) precise-proposed; urgency=low

  * debian/control
    - geoclue-examples shouldn't provide geoclue-provider (LP: #951496)
 -- Ken VanDine <email address hidden> Tue, 27 Mar 2012 14:25:01 -0400

Changed in geoclue (Ubuntu):
status: New → Fix Released
Revision history for this message
Bilal Akhtar (bilalakhtar) wrote :

Can you check if this issue still exists?

Changed in indicator-datetime (Ubuntu):
status: New → Incomplete
Revision history for this message
thehighhat (thehighhat) wrote :

This bug still exists.

If geoclue-ubuntu-geoip is not installed (eg, a deb that provides geoclue-provider is installed) then indicator-datetime-service consumes about 5MB/s nonstop.

Revision history for this message
Dave Vree (hdave) wrote :

I can confirm this bug is NOT FIXED in 13.10.

Revision history for this message
Charles Kerr (charlesk) wrote :

@hdave, Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:

* Is this reproducible?
* If so, what specific steps should we take to recreate this bug?

This will help us to find and resolve the problem.

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.