FS#24760 - [gtk2] X process uses 100% cpu when a gtk2 app is running

Attached to Project: Arch Linux
Opened by Tom Wadley (doogle) - Friday, 17 June 2011, 17:59 GMT
Last edited by Ionut Biru (wonder) - Sunday, 19 June 2011, 07:50 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Ionut Biru (wonder)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:

I am running KDE4. When I start a gtk2 app (such as the gimp) my X process jumps to 100% cpu usage and stays there until I have closed all gtk2 apps.

Additional info:

The problem appeared after upgrading to gtk2-2.24.5-1-x86_64
The problem went away when I downgraded to gtk2-2.24.4-2-x86_64

Steps to reproduce:

Launch a gtk2 app
This task depends upon

Closed by  Ionut Biru (wonder)
Sunday, 19 June 2011, 07:50 GMT
Reason for closing:  Fixed
Additional comments about closing:  commit reverted until upstream decide what to do

gtk2 2.24.5-2
Comment by Tom Wadley (doogle) - Friday, 17 June 2011, 18:04 GMT
In case it's relevant, I use the nvidia driver.
Comment by Ionut Biru (wonder) - Friday, 17 June 2011, 18:11 GMT Comment by Heiko Baums (cyberpatrol) - Friday, 17 June 2011, 21:36 GMT
The same happens with an ATI card and Xfce4.
Here X permanently eats at least 90% of one CPU core.
Additionally xfce4-netload-plugin eats up about 21% CPU while it usually only needs 1%.
Comment by Heiko Baums (cyberpatrol) - Friday, 17 June 2011, 21:45 GMT
@Ionut: Is that your new habit to let the user (users usually are not developers) test every single patch which was added by upstream into the new software release? Don't you think that either you as the downstream developer, who most likely has or at least should have more knowledge about that, should do that, or first check if your package (PKGBUILD, dependencies, configure options etc.) is correct, or file an appropriate bug report to upstream if you think that your package is correct, or downgrade your package to the latest working version until this bug is fixed (either by upstream or by having tested it a while longer in [testing])? Or don't you think that bisecting this is upstream's job if you think your downstream package is ok?
Comment by Ionut Biru (wonder) - Friday, 17 June 2011, 21:46 GMT
i'm not affected by this bug and cannot really do this by myself
Comment by Heiko Baums (cyberpatrol) - Friday, 17 June 2011, 21:52 GMT
But I as a user can't do it, too. So, like I said before, you should check your package and if you think this is completely correct and think it's an upstream issue, you should file an upstream bug report or ask the reporter to file a bug report to upstream. But checking every single commit done by upstream is really above a user.

And if you're sure that it's an upstream issue, then you should downgrade this package as long as the bug is fixed by upstream, because this bug is not a minor bug.
Comment by Ionut Biru (wonder) - Friday, 17 June 2011, 22:01 GMT
lets look at the commits list. majority are documentation + some G_CONST_RETURN to const+win32 that can be discarded and we end up with 3 or 4 commits that matter.

if i were in your place i will start by reverting this. just add before ./configure patch -NRp1 -i $srcdir/patchname

http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=254b9a4c540e3dff1dcd17db2ceea6a9fa5df973
Comment by Heiko Baums (cyberpatrol) - Friday, 17 June 2011, 22:23 GMT
Most usual users won't be able to do this, and I'm pretty sure that upstream know their code and their changes a lot better.

Here's the upstream bug report:
https://bugzilla.gnome.org/show_bug.cgi?id=652872
Comment by Spilver (DiS) - Saturday, 18 June 2011, 15:50 GMT
The same problem in Xfce 4.8, after wake up from suspend mode. (Xorg (ver. 1.10.2-1), Nvidia (ver. 275.09.07-1), GTK2 (ver. 2.24.5-1)). x86_64
Comment by lorim (lorim) - Sunday, 19 June 2011, 07:43 GMT
reverting that commit fixes the issue here, x86_64/kde/nvidia

Loading...