Ubuntu

ibus-daemon applet leaks memory badly

Reported by Graeme on 2010-05-21
96
This bug affects 18 people
Affects Status Importance Assigned to Milestone
ibus (Ubuntu)
Undecided
Unassigned
Lucid
Undecided
Unassigned

Bug Description

Binary package hint: ibus

The ibus-daemon gtk applet leaks memory. After a few days of running, memory usage climbs to over 130MB:

root 2173 0.0 0.0 103416 2336 ? Sl May18 0:00 \_ /usr/lib/gdm/gdm-session-worker
graeme 2211 0.0 0.2 168028 8352 ? Ssl May18 0:00 \_ gnome-session
graeme 2243 0.0 0.0 64260 3320 ? Sl May18 0:50 \_ /usr/bin/ibus-daemon --xim
graeme 2247 0.0 0.0 62188 3280 ? S May18 0:00 | \_ /usr/lib/ibus/ibus-gconf
graeme 2249 0.0 3.2 357844 133212 ? S May18 1:03 | \_ python /usr/share/ibus/ui/gtk/main.py

Right clicking on it and choosing "restart" from the menu causes it to quit, reload, and go back down to (a still pretty hefty) 26MB:

root 2173 0.0 0.0 103416 2336 ? Sl May18 0:00 \_ /usr/lib/gdm/gdm-session-worker
graeme 2211 0.0 0.2 168028 8360 ? Ssl May18 0:00 \_ gnome-session
graeme 2243 0.0 0.0 64180 3764 ? Sl May18 0:50 \_ /usr/bin/ibus-daemon --xim
graeme 27605 0.2 0.0 62192 3484 ? S 11:44 0:00 | \_ /usr/lib/ibus/ibus-gconf
graeme 27607 2.8 0.6 247732 26664 ? S 11:44 0:00 | \_ python /usr/share/ibus/ui/gtk/main.py

Rinse and repeat.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: ibus 1.2.0.20091215-1ubuntu4
ProcVersionSignature: Ubuntu 2.6.32-22.33-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-22-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Fri May 21 11:42:53 2010
ProcEnviron:
 PATH=(custom, user)
 LANG=en_CA.utf8
 SHELL=/bin/bash
SourcePackage: ibus

Graeme (unit3) wrote :
Graeme (unit3) wrote :

Also, look at the virtual memory usage. Even after restarting, it still thinks that it needs an address space of over 240MB. Clearly something is wrong with this app.

David Oftedal (rounin) wrote :

I had it climb to 21% of available memory, which should be about 831.18MB?

David Oftedal (rounin) wrote :

The IBUS project uses Google Code and Google Groups and not Launchpad for project management, though, so it's not guaranteed that they'll see this bug report unless it's reported there.

They also have an IRC channel on Freenode.

Graeme (unit3) wrote :

David,

Good to know, but doesn't that mean the package maintainers should open a ticket upstream and link it here after they've verified the problem? That's what I've always assumed the process is, anyway.

David Oftedal (rounin) wrote :

Possibly... I wouldn't be able to say whether that happens in practice, though.

David Oftedal (rounin) wrote :

↑ It would seem that it does, since clicking on "ibus (Ubuntu)" above yields a number of bug reports with activity in them. So presumably it will be noticed, then.

LI Daobing (lidaobing) wrote :

From: http://code.google.com/p/ibus/issues/detail?id=920

replied by Shawn.P.Huang:

Please try the latest version.
You could update from my ppa. You could find the detail from
http://code.google.com/p/ibus/wiki/ReadMe .

David Oftedal (rounin) wrote :

Thank you both! This new version does not seem to leak memory at all; the memory usage stays fixed at 0.9%.

L. David Baron (dbaron) wrote :

After I've been logged in for a few weeks, this python process (same as in the bug description) gets to using half a gig or more of ram on my laptop; killing the process noticeably improves system responsiveness. It seems like the fix ought to be part of an update for Lucid.

Rob Latham (rob-terizla) wrote :

Li Daobing's suggestion (#8) to update from Shawn P Huang's PPA does seem to help the problem quite a bit. There is a much much smaller leak of about 2 bytes per input method switch, but that is much better than the version in 10.4

Peng Huang (shawn-p-huang) wrote :

Hi Rob Latham,

How did you find the memory leak of 2 bytes per input method switch? Which process leaks the 2 bytes?

Lanoxx (lanoxx) wrote :

Confirmed:
Uptime of my notebook is 19 days now, and this little plugin has already climbed up to 520MB. Clicking to restart removes the process, eventhough I have 4GB of memory, spending one eight of it for an IME tool seems a bit much ^^

Duong H. Nguyen (cmpitg) wrote :

Not a work-around but I always use "ibus-daemon --replace" after a while to kick off Python's garbage collector to free up some memory. It's useful for long up-time computers.

JohnFlux (johnflux) wrote :

The latest ibus packages fix this. Add:

deb http://ppa.launchpad.net/shawn-p-huang/ppa/ubuntu lucid main

to your /etc/apt/sources.list file and upgrade. Make sure you install the python-notify package.

Can we please get these packages integrated into updates?

This bug shows up as a memory leak in plasma-desktop at a rate of 250kb/sec.

Jonathan Riddell (jr) on 2010-09-01
Changed in ibus (Ubuntu):
milestone: none → ubuntu-10.10
tags: added: kubuntu
Duong H. Nguyen (cmpitg) wrote :

@JohnFlux:

Installing newest iBus from Shawn P. Huang's PPA made my input method (ibus-unikey) unusable. I have asked him on the iBus user mailing list several times but somehow my post were never moderated. Disappointed...

Jonathan Riddell (jr) on 2010-09-09
tags: removed: kubuntu
Changed in ibus (Ubuntu):
milestone: ubuntu-10.10 → none
gene (eugenios) wrote :

Hi. Mine does not get to aforementioned extremes, but it might if my uptimes get longer (which is inhibited by another issue) Well using "ibus-daemon --replace" is nice, although it leaves a zombie behind.
One could actually start or reissue "ibus-daemon --replace" in the limited shell. I use it for similar memory loving apps, like gnome-stardict
Say, start a terminal and execute

$ ulimit -v 307200 -m 20480 #or similar, where -m and -v are the actual memory virtual memories in kb, resp.
and then
$ ibus-daemon --replace

When the greedy python process gets to the maximum limit it exits and the applet is gone, one can then restart ibus-daemon from the same limited shell.

It turns out, that I don't really need that applet, so I am figuring how to dispense with it completely.

gene (eugenios) wrote :

In my case Shawn Huang's ppa shawn-p-huang/ppa/ubuntu seems to fix it. The associated python process does not exceed 20MB. Although, the language window does not pop-up anymore, the ibus applet only shows the switch (maybe I have to logout-login). I am 100% satisfied with this.
Actually, apt-get could not handle the upgrade, aptitude could.

gene (eugenios) wrote :

All right, who is going to bring shawn's ppa into the official repositories so that rest of the users would benefit from it?

Tomofumi (tomofumi) wrote :

Just discover this bug when my system response is bad, check from the top:
 2188 user 20 0 1073m 592m 5988 S 0 19.7 6:46.39 python
and find out that python is:
$ ps -ef | grep 2188
user 2188 2176 0 Feb08 ? 00:06:46 python /usr/share/ibus/ui/gtk/main.py
that's crazy for an IME used so much memory. Still no official upgrade for this package?

Changed in ibus (Ubuntu Lucid):
status: New → Confirmed
Changed in ibus (Ubuntu):
status: New → Confirmed
Xiaojun Ma (damage3025) wrote :

Hi, all.

It's 2012.
Several things changed.
The upstream issue is already closed.
Shawn Huang's PPA is no longer maintained.
Ubuntu 12.04 comes with latest stable release of IBus.

I'd like to whether newer version of IBus still have this issue?
If not, I'd like to close this bug as "Fix Released".

L. David Baron (dbaron) wrote :

This seems fixed to me in Ubuntu 11.10. I'm currently seeing:

$ ps auwwx | head -1; ps auwwx | grep main.py | grep -v grep
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
dbaron 2142 0.0 0.1 483600 11304 ? Sl Jun15 8:43 /usr/bin/python /usr/share/ibus/ui/gtk/main.py

That is, 11meg RSS after 22 days.

Xiaojun Ma (damage3025) wrote :

Close as Fix Released.

Correct me if I'm wrong.

Changed in ibus (Ubuntu Lucid):
status: Confirmed → Invalid
Changed in ibus (Ubuntu):
status: Confirmed → Fix Released
no longer affects: ibus
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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