After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 652872 - gtk 2.24.5 causes X and other tools to high CPU usage
gtk 2.24.5 causes X and other tools to high CPU usage
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
2.24.x
Other Linux
: Normal major
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2011-06-17 22:20 UTC by Heiko Baums
Modified: 2011-09-05 04:08 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Heiko Baums 2011-06-17 22:20:00 UTC
After the update from gtk 2.24.4 to 2.24.5 xorg permanently eats up more than 90% CPU usage on one CPU core, and xfce4-netload-plugin permanently uses about 21% CPU usage, while they usually are only using about 6% and 1%.

After downgrading gtk to 2.24.4 the issue goes away.

This happens at least under Arch Linux (x86_64) with
kernel 2.6.39.1
xorg-server 1.10.2
xfce 4.8.0
xfce4-netload-plugin 1.0.0

This issue seems to appear on KDE, too, as mentioned in this downstream bug report: https://bugs.archlinux.org/task/24760
Comment 1 Benjamin Otte (Company) 2011-06-18 13:12:42 UTC
Hrm, I cannot reproduce this. I'm on Fedora 15, so there might be differences I don't know about, but I'm using GTK 2.24.5 and the same xfce versions here.

From the Arch bug it looks like there's something that is causing an infinite loop somehow, but I have no idea what that could be. And it could be anywhere in the stack... To do an educated guess for that, I'd need a system-level profiling log, but I don't know of any tool that provides this other than sysprof on a system that's compiled without -fomit-frame-pointer

Bisecting it might also help, in case it's not caused by http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=254b9a4c540e3dff1dcd17db2ceea6a9fa5df973
Comment 3 Rafał Mużyło 2011-06-18 16:46:35 UTC
Note also http://bugs.gentoo.org/show_bug.cgi?id=372087 - as GDK_NATIVE_WINDOWS works around that problem, it's most likely same commit (after all, there weren't that many between .4 and .5).
Comment 4 Rafał Mużyło 2011-06-19 05:12:46 UTC
FYI: confirmation from freeciv upstream - http://gna.org/bugs/?18243
Comment 5 Roberto Malinverni 2011-06-19 07:36:26 UTC
another bug related to 2.24.4 -> 2.24.5 update:
https://bugzilla.gnome.org/show_bug.cgi?id=652925
Comment 6 Antoine Jacoutot 2011-06-27 07:24:38 UTC
One of our users sees the same issue on OpenBSD when using pidgin. Reverting the aforementioned commit "fixes" it.
Comment 7 Jacob Nevins 2011-07-05 20:50:26 UTC
I'm from Freeciv upstream.

I see the "Make background changes queue a repaint" commit has been reverted post-2.24.5:
http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=d7ac9cd71c43689672a9796e518ef3b970197bf2

Is that the final resolution of this issue? Are we likely to have to make any changes to the Freeciv code in order to remain compatible with future Gtk 2.x?
Comment 8 Benjamin Otte (Company) 2011-07-05 21:40:38 UTC
I think the revert is final, as there were quite a few issues with it, and I don't want to cause with maintenance-only code.

That said, I do think something is indeed wrong in your rendering code if it causes FreeCiv to turn black, so looking at the issue probably wouldn't hurt. Who knows what's happening there...