Bug 143255 - Superkaramba makes X.org unresponsible
Summary: Superkaramba makes X.org unresponsible
Alias: None
Product: superkaramba
Classification: Miscellaneous
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Ryan Nickell
: 138196 (view as bug list)
Depends on:
Reported: 2007-03-20 13:53 UTC by Petr Kopecký
Modified: 2009-07-16 23:49 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:

Revert the code of kwin_layers.cpp without rebuild entire kdebase3 sources (for openSuSE) (1.20 KB, application/octet-stream)
2008-04-11 15:18 UTC, Alex
Gentoo ebuild to revert the code of kwin_layers.cpp. (722 bytes, application/octet-stream)
2008-04-11 15:19 UTC, Alex
Fix the 100% CPU issue with SuperKaramba and Kwin (417 bytes, patch)
2008-08-28 19:21 UTC, jaguarwan

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Kopecký 2007-03-20 13:53:57 UTC
Version:           3.5.6 (using KDE KDE 3.5.6)
Installed from:    Gentoo Packages
Compiler:          gcc 4.1.1 
OS:                Linux

When KDE is running in idle (without any user actions) and superkaramba is running then after some time CPU occupation increases. CPU occupation comes to normal if I start using KDE again. Looking at top list I can see that it is X CPU occupation (not superkaramba). If I let KDE in idle for a long time (2 hours) X becomes unresponsible and usually even Ctrl+Alt+Backspace doesn't help and I have to reset computer. I am using X.org 7.1.1. 

I did some observations and here is the result:
1) The problem was not present in KDE 3.5.5
2) When superkaramba is not running the problem is not present
3) If only one superkaramba applet is running the problem is not present
4) I have tried to download and compile superkaramba 0.39 from superkaramba home page but the behaviour is the same
5) killall superkaramba and starting new instance doesn't help. 
6) Working on computer whole day the problem doesn't occur - it only occurs when KDE is not used (in idle)
Comment 1 Paul Peltz 2007-03-28 17:42:36 UTC
I'm having the same problem and can reproduce this behavior.
Comment 2 Krisztian Toth 2007-05-11 14:14:35 UTC
I can confirm this bug too on my Kubuntu Feisty (Kubuntu 7.04)
KDE: 3.5.6

Here's the Ubuntu bug report about this problem:

Comment 3 Paul Peltz 2007-05-11 14:58:38 UTC
Can you vote for this bug then please?  Unless it gets more votes it won't be confirmed.  Thanks.
Comment 4 Krisztian Toth 2007-05-13 07:33:43 UTC
*** This bug has been confirmed by popular vote. ***
Comment 5 Krisztian Toth 2007-05-13 07:36:36 UTC
Thank you for reminding me! I forgot to vote. Now I did it.
Comment 6 footer 2007-06-08 14:02:26 UTC
I voted for this bug.  I have two Superkaramba applets running on my desktop (Kubuntu Feisty Fawn 7.04, KDE 3.5.6).  My desktop freezes after sitting idle for awhile but only for 20-30 seconds after which I can use it again.  Very ANNOYING problem!

Comment 7 geekbanter 2007-06-15 21:52:45 UTC
Same problem here on PCLinuxOS 2007.  Problem initially started when leaving the desktop locked overnight and in the morning the computer was unresponsive.  It took a while to narrow my problem down to superkaramba in general, and not a specific applet.  It seems like the more applets running the more severe the problem.

No superkaramba, all is fine idling overnight.
Three simple applets (clock,tmon,wifi) and desktop is sluggish or unresponsive for a minute after idling for several hours (CPU=100% for X).
Five applets (add liquid weather and gsm) after a several hour lock and on a few overnight occasions X will not respond beyond showing the password dialog.  Trying to kill X (Ctrl+Alt+Bksp) will lock the system

As mentioned by others the problem does not exist while the computer is being used, even all day long.

CPU: AMD64 3000+
MB: A8N-SLI Premium
VGA: Nvidia Geforce 7600GT w/Nvidia 97xx drivers
Xorg: 7.0.1
KDE: 3.5.6
Comment 8 Petr Kopecký 2007-06-16 16:04:45 UTC
Seems to me that the problem is not present in KDE 3.5.7. Could anybody else confirm it?
Comment 9 Markos 2007-06-17 13:06:18 UTC
Same Problem here on Gentoo linux  with KDE 3.5.7 and superkaramba
Comment 10 footer 2007-06-17 15:24:16 UTC
I still have the problem with KDE 3.5.7.  I've only had it installed for about 24 hours but it's happened to me once already (though it was only about a 20 second freeze so maybe it's improved?).

Unfortunately, KDE 3.5.7 seems to have brought on another bug, the dreaded "Received signal 15, shutting down cleanly" bug referenced here:


I have not had this bug in awhile and KDE 3.5.7 is the only upgrade recently so not sure what's going on.

Comment 11 Alexander Wiedenbruch 2007-08-25 00:26:18 UTC
You all report that this happens when your computer is idling, so I assume that you use a screensaver for now.

A bug was already posted about a similar problem:

It is possible that this behaviour of xscreensaver makes X unresponsive.

So I would like to check this out first.
So please tell me if you use a screensaver or xcreensaver and what happens when you don't use one at all?

Besides that I currently have no other idea, but I'll try to investigate further.

Comment 12 footer 2007-08-25 00:31:22 UTC
Sorry, no screen saver here.  Just power saving monitor feature after 10 minutes (Kubuntu Feisty Fawn 7.04).
Comment 13 geekbanter 2007-08-25 01:50:39 UTC
I don't use superkaramba anymore because of this problem.  Back when I was having the problem I didn't use a screensaver, but I also had the monitor go to sleep after about 15 minutes. (PCLinuxOS 2007 - KDE 3.5.7)
Comment 14 Jan Michelsburg 2007-08-25 09:53:33 UTC
No screensaver, no power saving feature. But got the same problem again yesterday after activating a second theme.
Comment 15 footer 2007-08-25 13:53:02 UTC
I forgot to point out that from the original post:

     3) If only one superkaramba applet is running the problem is not present

This has been my experience as well.  If I leave just one applet running, I don't experience this problem.
Comment 16 Ujeen 2007-08-26 09:09:49 UTC
I have the same situation on 2 my computers (desktop and laptop). I stopped using superkaramba and the issue disappeared.
Comment 17 Daniel 2007-09-02 21:12:39 UTC
Confirming presence of behavior on OpenSuse 10.2 + some updates.
X v7.1.99.902
SK 0.42
KDE 3.5.7

Intel 810/815 chipset / video adapter, non-proprietary, pure Xorg driver. Compositing enabled. Screensaver enabled with "blank screen" mode.

Was running "Translate Plus", "Desktop Basket", "Horovod", the new (SVN) version of Kaddressbook theme. After 5 hours of inactivity, Xorg thread was using 70-100% of CPU (according to top) and did not respond to clicks on any of the widgets.

Since X stops responding to CTRL+ALT+F# keypresses, the only way to switch away from "frozen" X to a console was to induce suspend-to-disk and switch (CTRL+ALT+F1) to console right before X is fully re-activated.

After switching to console in such a way, I was able to killall superkaramba, all python threads, anything related to superkaramba, yet X showed same 80-100% CPU usage. Killing X, and letting kdm restart it, of course, brings the system to normal.

Inspecting the "ps aux" and "top" output during the "100%" behavior and in normal conditions do not show much difference in terms of superkaramba memory consumption. Xorg consumed considerably more memory during "100% CPU" period (92Mb ps aux)(190+Mb top) compared to normal condition (56Mb ps aux)(139Mb top). (Interestingly, "ps aux" does not show Xorg consuming cpu, while top does...)

Next, I will try to: 1) turn the screensaver off, 2) turn composite off, 3) run some python-less themes and see if the behavior continues to occur.
Comment 18 Petr Kopecký 2007-09-02 21:24:48 UTC
It is strange that the bug disappeared on my system after upgrading to KDE 3.5.7 while on others it is still present. I don't know what else changed on my system. 
Comment 19 Daniel 2007-09-03 07:32:12 UTC
Continuing troubleshooting:

Specs again:
X v7.1.99.902 
SK 0.42 
KDE 3.5.7 
Intel 810/815 chipset / video adapter
non-proprietary, pure Xorg driver for intel81x

As promised previously, tested the following 3 configurations:
Level 1. Switched to python-less themes
Level 2. Turned off screen-saver completely,
Level 3. Turned off "Composite" extension.

Everything else the same + level 1 = this bug still occurs.
In fact, using 4 copies of the same monitor theme with 1 second refresh and lots of chart/meters reliably reproduced the bug in 30-40 minutes.

Level 1 + 2. Checked, neither xscrensaver, nor kscreensaver is running. Bug is present, with NO change in character. It is NOT caused by the screen saver.

Level 1+2+3. COmposite extension OFF. (Both, GLX and DRI extensions stay enabled) Bug DISAPPEARS. Disabling composite extention makes system run normal in idle. The longest I waited is 2 hours. Considering that previously the bug would show up in 30 minutes, this may be our reasonable clue. I will try running on idle in this configuration again, over night, and see if non-composite set up just delays the problem or really alleviates it.

Questions to others:
- if you experience this problem, what is your video chipset / video driver / composite off/on?
Comment 20 Petr Kopecký 2007-09-03 20:26:10 UTC
I have GeForce 7600 GS adapter, proprietary NVidia driver is used, and this is the beginning of xdpyinfo. You can see that composite is switched on because I am using compiz-fusion.

# xdpyinfo
name of display:    :0.0
version number:    11.0
vendor string:    The X.Org Foundation
vendor release number:    70200000
X.Org version: 7.2.0
maximum request size:  16777212 bytes
motion buffer size:  256
bitmap unit, bit order, padding:    32, LSBFirst, 32
image byte order:    LSBFirst
number of supported pixmap formats:    7
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 4, bits_per_pixel 8, scanline_pad 32
    depth 8, bits_per_pixel 8, scanline_pad 32
    depth 15, bits_per_pixel 16, scanline_pad 32
    depth 16, bits_per_pixel 16, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
    depth 32, bits_per_pixel 32, scanline_pad 32
keycode range:    minimum 8, maximum 255
focus:  window 0x2e00008, revert to PointerRoot
number of extensions:    32
default screen number:    0
number of screens:    1
Comment 21 Petr Kopecký 2007-09-03 20:28:34 UTC
Sorry I have forgotten to write that I don't have the problem any more even that I use composite extension. The problem disappeared after upgrading to KDE 3.5.7.
Comment 22 Daniel 2007-09-04 01:01:50 UTC
Checked overnight. The bug occurs even with Composite, GLX, DRI, DBE extensions OFF. I thought for a while it's some sort of double-buffering inefficiency, or some other "accelerated" feature problem... No. This has something to do with core X. Either threading issues, or some other unusual, hard-to-catch problem.

It is rather hard to imagine how we are going to catch it, and what actually caused this: a change in Xorg, or a change in SK...
Comment 23 Hitman1 2007-09-14 23:07:55 UTC
I'm experiencing the same problem here with MEPIS 7.0 Beta4
Kde 3.5.7
superkaramba 0.42

I just turned off superkaramba after reading this thread; first idle night without an xorg hang. Lets see how it goes the 2nd night. 
Comment 24 Scott Grayban 2007-10-31 03:37:12 UTC
I have the same problem as well.

$ kde-config --version
Qt: 3.3.8
KDE: 3.5.6
kde-config: 1.0
X: 1.2.0

This is a real shame -- the svn version (.42) works just fine in KDE 3.4 -- its completely broken in KDE 3.5
Comment 25 Alessandro Pra' 2007-11-10 23:13:43 UTC
Same problem for me too:
- Kubuntu Feisty 7.04
- KDE 3.5.7
- ATI Radeon 7500 with open drivers
- xorg 7.2
- superkaramba 0.41

I just came to know of the relationship between the problem and superkaramba, still have to try if disabling it "solves" the problem... if disabling one of KDE's coolest features can be called a solution. I'll bring more info in a couple of days of tests.
Comment 26 Alessandro Pra' 2007-11-11 20:35:14 UTC
Up to now, with SK totally shut off, no occurrances of the problem. Now I'm going to test what happens leaving superkaramba running with only one theme loaded.
Comment 27 Alessandro Pra' 2007-11-13 22:08:59 UTC
I've been with SK running with only one theme, and still no occurance of the problem.
Comment 28 Scott Grayban 2007-11-14 02:11:56 UTC
X dies when 2 or more SK themes are running.

Having only 1 SK theme running does not hurt X at all.
Comment 29 CK 2007-11-25 02:08:11 UTC

I'm using KDE 3.5.8. on Unix, i can confirnm the problem. If i do not use the computer for about an hour, Xorg starts to use 100% CPU and computer does not response to any command.


Comment 30 CK 2007-11-26 17:40:49 UTC
Additional information: If only one applet is active, and if computer is idle for about 2 hours, CPU usage stays around 40 ~ 60 % and computer responds keyboard and mouse activities and back to normal.

Comment 31 jaguarwan 2007-12-11 09:16:03 UTC
I have this bug too, if I let sit my laptop idle (Core Duo, i945gm intel gpu) Xorg CPU usage will slowly increase to 100% over time. If I close superkaramba the issue disappears. Curiously, simply clicking several times on the desktop or in an open shell window will bring back Xorg CPU consumption to normal quite instantaneously.
Comment 32 Guitch 2007-12-19 04:31:53 UTC
Same problem here with Debian Unstable :
Qt: 3.3.7
KDE: 3.5.8
kde-config: 1.0
X.Org X Server 1.4.0
NVIDIA proprietary driver 96.43.01, Composite enabled
Superkaramba 0.42

The bug appears after about 30 minutes, if I click on the desktop, Xorg CPU consumption sometimes goes back to normal, otherwise, Ctrl-Alt-Backspace.

Comment 33 Magnus Bjureblad 2007-12-30 11:00:37 UTC
Have the same problem. Solved when SK is shutdown.
Kubuntu 7.10 (KDE, SK, QT - all Ubuntu packages)
ATI Radeon 9800, ATI driver 8.40.4

Same behavior as Guitch (comment #32)
Comment 34 Alexander Wiedenbruch 2008-01-12 20:33:49 UTC
Can someone please confirm if this still happens with KDE 4.0 or not?
Comment 35 jaguarwan 2008-01-14 14:11:51 UTC
I think this bug may be tied to something in kwin, because I tried compiz-fusion this afternoon with the exact same superkaramba widgets I use everyday, and the CPU usage raise did not occur at all. Since the only KDE component that compiz-fusion replace is kwin, I think maybe the bug lies somewhere in there?
Comment 36 footer 2008-01-14 14:18:02 UTC
Sorry but I beg to differ.  I've been using compiz-fusion for a long time and the same two superkaramba widgets equally as long and if I leave both of them running and come back several hours later, she's froze up!  It takes from 30-45 seconds to break free again (thankfully, no hard reset).  As long as I leave only one superkaramba widget on the desktop though, no problem.  Xorg CPU and memory usage definitely climbs with more than one widget open with compiz-fusion.
Comment 37 jaguarwan 2008-03-12 12:32:50 UTC
OK 哥们儿s, I did more testing and here is my results:
* The bug does not occur with only one widget (the docker kroller)
* The bug still occurs on KDE 3.5.9 with the two widgets (kroller + Borealis)
* The bug does not occur with compiz, which lead me to suspect kwin
* I tested running the kwin from KDE 3.4.3, since I only remember having this bug since the 3.5.x serie, and the bug does *not* occur anymore with the two widgets active and kwin 3.4.3.

=> between kwin 3.4.3 and 3.5.x, some change was introduced which triggered this bug. Since it's X that is eating CPU cycles and not kwin, I guess kwin must issue many X calls for some reason without getting stuck in a loop itself.

So in my case at least, the window manager is definitely involved.
Comment 38 jaguarwan 2008-03-12 15:48:18 UTC
Actually, as the original reporter said, I don't have any problem either using kwin 3.5.5. So the change that cause this bug must be in the changeset between kwin 3.5.5 and 3.5.6.
Comment 39 jaguarwan 2008-03-12 23:19:52 UTC
OK, after selectively testing reverting changes to every modified source file between 3.5.5 and 3.5.6, it appears that the changes to layers.cpp caused the bug to appear, but I don't understand why yet. For the most impatient, you can just make a diff between 3.5.6 and 3.5.5 layers.cpp and apply it to 3.5.9,the bug will be fixed.
Comment 40 Scott Grayban 2008-03-12 23:36:46 UTC
Is layers.cpp part of KDE source or SK source ?

Would you mind posting a diff for the technically challenged ?
Comment 41 jaguarwan 2008-03-13 00:06:20 UTC
layers.cpp is in kwin sourcecode, in the kdebase package. I'm still trying to narrow down the diff to find the real source of the bug, I will post one as soon as I find the offending lines (not just revert to 3.5.5 layers.cpp).
Comment 42 Scott Grayban 2008-03-13 00:10:07 UTC
Ok thanks
Comment 43 jaguarwan 2008-03-13 01:16:28 UTC
OK, this diff fixes the bug on my configuration:


--- kdebase-3.5.6/kdebase-3.5.6/kwin/layers.cpp	2007-01-15 12:32:14.000000000 +0100
+++ kdebase-3.5.5/kdebase-3.5.5/kwin/layers.cpp	2006-05-22 20:13:01.000000000 +0200
@@ -117,11 +117,7 @@
     if( changed || propagate_new_clients )
-        {
         propagateClients( propagate_new_clients );
-        if( active_client )
-            active_client->updateMouseGrab();
-        }


Put it in the kwin source directory and apply with:
patch -p3 < whatever_you_name_the_diff.diff

Then compile to go back to the sane 3.5.5 behaviour.

I checked if this could come from updateMouseGrab(), but apparently some changes made to it from 3.5.5 from 3.5.6 were already reverted. I must confess that I don't know very well how these innocent looking lines trigger the bug, but I would be grateful if you could test this patch for possible regressions and apply it to SVN, so this really annoying bug can be finally solved :)
Comment 44 Scott Grayban 2008-03-13 12:19:49 UTC
That seems to have fixed for me also. KDE no longer hangs on any of my boxes including the 3 different distros I use here, Mandriva, debian and gentoo.

Great work jaguarwan for figuring this out.

On the side note I have no clue what those lines do and I don't see anything that regressed or even broke from removing those lines out. All my desktops work just fine. All mouse functions work just like they did before so that is a good sign that nothing was broken doing this.

I will pass this along to Ryan who is one of the coders for SK so that they are aware of this possible fix and that it isn't SK fault.
Comment 45 Scott Grayban 2008-03-14 18:13:57 UTC
Bug #128648 broke this.
Comment 47 Lubos Lunak 2008-03-14 18:57:29 UTC
The real bug is presumably https://bugs.freedesktop.org/show_bug.cgi?id=2738 .
Comment 48 Scott Grayban 2008-03-15 01:07:31 UTC
I think Xorg fixed that bug already and your patch in KDE is overkill and causing more bugs. As stated if we remove your code everything works ok.
Comment 49 Lubos Lunak 2008-03-17 00:02:19 UTC
Who is comment #48 aimed at? Me?
Comment 50 Scott Grayban 2008-03-17 00:09:24 UTC
Comment 51 Scott Grayban 2008-03-17 00:11:28 UTC
If your patch is suppose to fix a bug, which apparently has been fixed by xorg, and now its causing more problems as with SuperKaramba then your patch needs to be removed.
Comment 52 Lubos Lunak 2008-03-17 15:57:23 UTC
No. My patch, which people here are suggesting to remove, was to fix another problem, and only triggers the x.org bug.
Comment 53 Scott Grayban 2008-03-17 16:32:56 UTC
So let me get this straight here.

You fixed a KDE program bug that in turn broke another KDE program to fix a bug that was originally xorgs bug?

Why should superkaramba users suffer for a program you or others like instead? Is there some order of "My stuff is better then your stuff" rule here?

Instead why haven't you forced the bug to be fixed upstream instead of not fixing anything with your patch?

Sorry but I just don't follow the logic here and I certainly do not accept it. It is flawed and has caused another program to break.
Comment 54 Lubos Lunak 2008-03-17 18:46:20 UTC
No. Read what I wrote again. I fixed an unrelated problem and the fix triggers x.org bug.
Comment 55 Scott Grayban 2008-03-17 19:00:00 UTC
Your *unrelated* problem is about window focus, bug #128648, which in turn broke SK.

Do you not agree?

I don't have any window focus issues with or without your patch. So I still fail to see how *your* patch has helped.
Comment 56 Lubos Lunak 2008-03-20 18:39:58 UTC
*** Bug 138196 has been marked as a duplicate of this bug. ***
Comment 57 jaguarwan 2008-03-30 06:08:57 UTC
So, in the end, will this bug be fixed in the next version of KDE 3.5 ?
Comment 58 Scott Grayban 2008-03-31 00:57:15 UTC
looks like never from the answer i got
Comment 59 jaguarwan 2008-03-31 10:27:48 UTC
This bug pesters a lot of users since a long time, it would be nice if it could be fixed in one way or another in KDE 3.5.10. I find it quite funny than Alex from #138196 came up with the same patch in december :)
Comment 60 Lubos Lunak 2008-03-31 10:58:41 UTC
*sigh* This will not be fixed in KDE, since the bug is not in KDE, unless proven otherwise. The problem is in X and should be fixed in the latest version. Ignoring it or uselessly complaining is not going to change anything about that.
Comment 61 Scott Grayban 2008-03-31 11:14:14 UTC
That is *your* opinion.

But on the flip side why don't *you* prove it isn't a KDE bug since you are hell bent it isn't and it's all Xorg's fault.

The consensus here says it's a KDE bug. It is up to you to prove other wise since it was *YOU* that caused all this mess.
Comment 62 Scott Grayban 2008-03-31 11:21:30 UTC
The facts are this.

I disabled your stupid patch for kwin and *YET* everything works just peachy with my desktop -- even the *assumed* bug for window focus you claimed was there I do not see. It isn't in my version of KDE 3.5.7 nor is it in my 3D desktop so as far as I am concerned your patch broke SuperKaramba and you did it on purpose and you *refuse* to take responsibility for it. All *you* do is blame others.

Qt: 3.3.8
KDE: 3.5.7
kde-config: 1.0
Xorg: 7.1.0
Comment 63 Lubos Lunak 2008-03-31 12:20:24 UTC
No, the facts are this: The maintainer of the code says there is no bug in the code, while you ... well, what is your qualification actually, besides being apparently clueless about the issue? Come back when you actually do have facts, thank you. For additional input from me, please refer to comment #60.
Comment 64 Scott Grayban 2008-03-31 12:29:09 UTC
Typical god coder reply. Have you worked on GNOME code -- same attitude there as well, "we do no wrong".

As for my qualifications -- google me some day. Might learn something.

Your patch is crap and that is a fact.
Comment 65 Alex 2008-04-11 15:18:44 UTC
Created attachment 24297 [details]
Revert the code of kwin_layers.cpp without rebuild entire kdebase3 sources (for openSuSE)

Revert the code of kwin_layers.cpp without rebuild entire kdebase3 sources.
Tested only on openSuSE 10.3
Comment 66 Alex 2008-04-11 15:19:57 UTC
Created attachment 24298 [details]
Gentoo ebuild to revert the code of kwin_layers.cpp.
Comment 67 Alex 2008-04-11 15:23:47 UTC
For all those people that don't care about what is the best code, but wants only that the code works (as I am), I've done a script and an ebuild, to revert the code of kwin_layers.cpp, without rebuild entire kdebase3 sources.
The script, is for RPM based distros, but I've tested only on openSuSE 10.3.

The ebuild is (obviously) for Gentoo.

Have a nice day.
Comment 68 Scott Grayban 2008-04-11 15:26:44 UTC
It's about time that someone did some reverting. Shame the maintainers are so thick headed and do not care.

Even when the consensus agrees this patch is crap they still refuse to listen.
Comment 69 Alex 2008-04-11 15:32:48 UTC
I've done the script and the ebuild, for the users, not for the maintainers.
If some other user want a working code (ugly but working) can use my script, or my ebuild, otherwise he can ignore all my crap.
Comment 70 Scott Grayban 2008-04-11 15:35:56 UTC
The maintainers don't care so I wouldn't worry about them.
Comment 71 Decha 2008-05-10 10:26:38 UTC
Same issue here, Gentoo, kde-3.5.9.

Hope there would be some progress, have to stop using superkaramba for now...
Comment 72 jaguarwan 2008-08-28 19:19:53 UTC

I just installed KDE 3.5.10 on my Slackware-current running X.Org 1.4.2, and the bug is still alive and kicking. I'm about to recompile kdebase with my patch again...

It'd be nice if this patch could be applied upstream for KDE 3.5.11, since it's quite an annoying bug.

For what it's worth, here's the patch against 3.5.10...:

--- kdebase-3.5.6/kdebase-3.5.6/kwin/layers.cpp	2007-01-15 12:32:14.000000000 +0100
+++ kdebase-3.5.5/kdebase-3.5.5/kwin/layers.cpp	2006-05-22 20:13:01.000000000 +0200
@@ -117,11 +117,7 @@
     if( changed || propagate_new_clients )
-        {
         propagateClients( propagate_new_clients );
-        if( active_client )
-            active_client->updateMouseGrab();
-        }

Comment 73 jaguarwan 2008-08-28 19:21:06 UTC
Created attachment 27112 [details]
Fix the 100% CPU issue with SuperKaramba and Kwin

Hope this helps.
Comment 74 Jacopo De Simoi 2008-09-29 06:13:45 UTC
Can anybody confirm that the patch fixes the problem? I'm running the patched version and the cpu usage of X when idling keeps increasing as before (altough I did not wait to see if it was eventually going to freeze the system)

I'm running 3.5.9 if that matters anymore.

Comment 75 Scott Grayban 2008-09-29 06:57:34 UTC
I stopped using superkaramba since the KDE developers broke it and refuse to fix it. Since then I haven't gave KDE any good reviews seeing they don't care about correct/quality coding.
Comment 76 Mike Williams 2009-07-16 23:49:20 UTC
I'm closing this because the 3.5.X series will likely never see another release (based on all of the discussions I could find on the Internet), let alone one that fixes this instead of security flaws.