I'm having the same problem and can reproduce this behavior.

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:

https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/109507

Can you vote for this bug then please?  Unless it gets more votes it won't be confirmed.  Thanks.

*** This bug has been confirmed by popular vote. ***

Thank you for reminding me! I forgot to vote. Now I did it.

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!

Thanks!

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

Seems to me that the problem is not present in KDE 3.5.7. Could anybody else confirm it?

Same Problem here on Gentoo linux  with KDE 3.5.7 and superkaramba

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:

https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/94862

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.

ARGH!

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:
https://bugs.launchpad.net/ubuntu/+source/kdeutils/+bug/94345

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.

Thanks!

Sorry, no screen saver here.  Just power saving monitor feature after 10 minutes (Kubuntu Feisty Fawn 7.04).

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)

No screensaver, no power saving feature. But got the same problem again yesterday after activating a second theme.

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.

I have the same situation on 2 my computers (desktop and laptop). I stopped using superkaramba and the issue disappeared.

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.

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. 

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?

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
    BIG-REQUESTS
    Composite
    DAMAGE
    DOUBLE-BUFFER
    DPMS
    Extended-Visual-Information
    GLX
    MIT-SCREEN-SAVER
    MIT-SHM
    MIT-SUNDRY-NONSTANDARD
    NV-CONTROL
    NV-GLX
    RANDR
    RENDER
    SECURITY
    SHAPE
    SYNC
    TOG-CUP
    X-Resource
    XAccessControlExtension
    XC-APPGROUP
    XC-MISC
    XFIXES
    XFree86-Bigfont
    XFree86-DGA
    XFree86-Misc
    XFree86-VidModeExtension
    XInputExtension
    XKEYBOARD
    XTEST
    XVideo
    XVideo-MotionCompensation
default screen number:    0
number of screens:    1

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.

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...

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. 

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

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.

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.

I've been with SK running with only one theme, and still no occurance of the problem.

X dies when 2 or more SK themes are running.

Having only 1 SK theme running does not hurt X at all.

Hello!

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.

Regards,

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.

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.

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.

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)

Can someone please confirm if this still happens with KDE 4.0 or not?

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?

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.

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.

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.

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.

Is layers.cpp part of KDE source or SK source ?

Would you mind posting a diff for the technically challenged ?

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).

Ok thanks

OK, this diff fixes the bug on my configuration:

----------------------8<--------------------------

--- 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 @@
         }
 #endif
     if( changed || propagate_new_clients )
-        {
         propagateClients( propagate_new_clients );
-        if( active_client )
-            active_client->updateMouseGrab();
-        }
     }
 
 /*!

----------------------8<--------------------------

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 :)

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.

Bug #128648 broke this.

WebSVN diff

http://websvn.kde.org/branches/KDE/3.5/kdebase/kwin/layers.cpp?r1=603048&r2=603293

The real bug is presumably https://bugs.freedesktop.org/show_bug.cgi?id=2738 .

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.

Who is comment #48 aimed at? Me?

yes

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.

No. My patch, which people here are suggesting to remove, was to fix another problem, and only triggers the x.org bug.

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.

No. Read what I wrote again. I fixed an unrelated problem and the fix triggers x.org bug.

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.

*** Bug 138196 has been marked as a duplicate of this bug. ***

So, in the end, will this bug be fixed in the next version of KDE 3.5 ?

looks like never from the answer i got

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 :)

*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.

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.

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

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.

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.

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

Created attachment 24298 [details]
Gentoo ebuild to revert the code of kwin_layers.cpp.

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.

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.

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.

The maintainers don't care so I wouldn't worry about them.

Same issue here, Gentoo, kde-3.5.9.

Hope there would be some progress, have to stop using superkaramba for now...

Hi,

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 @@
         }
 #endif
     if( changed || propagate_new_clients )
-        {
         propagateClients( propagate_new_clients );
-        if( active_client )
-            active_client->updateMouseGrab();
-        }
     }
 
 /*!

Created attachment 27112 [details]
Fix the 100% CPU issue with SuperKaramba and Kwin

Hope this helps.

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.

Thx

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.

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.

http://mail.kde.org/pipermail/release-team/2008-August/002390.html