Bug 138196

I've never seen that, so you'll need to provide more information: After this occurs, change to text console, log in there, find the pid of kwin ("pidof kwin"), run "gdb -p <pid>" and type "bt" to get the backtrace (and "quit" to leave afterwards). Then attach the backtrace here, possibly several of them if they differ on different runs (you gpm to copy&paste them or run gdb as "gdb -p <pid> | tee /tmp/gdb.txt" to also write the output to a file).

Waiting for a response.

I can confirm this. Using two different PC 
- SuSE 9.3, Matrox G450 Dual-Head, KDE 3.5.6
- SuSE 10.1, Nvidia GForce, Dual-Head, KDE 3.5.6

The problem came up with KDE 3.5.5. The "X"-process consumes nearly 100% CPU. I've to switch to the text console and do a killall -9 X as there is no response to "Ctrl-Alt-Backspace".

In my case, the screen has to be in suspend mode for a longer time (> 30 minutes). And not always the problem occurs. I didn't assign this to kwin, because the X-server itself eats my cpu.

The next time i get this error i will try to do a gdb and attach the trace.

Created attachment 20216 [details]
Two backtraces of kwin when kwin "hangs"

Archive contains two (back)traces from a KDE session hanging. When this
happened, the "window decorations" where gone and there is no response of any
window. Mouse moving is still possible. Keyboard input too, but not visible
response (f.e. in Konsole's terminal window.

Looking with "top" or "ps" for the proccess status, the "X"-server consumes
about 95%-98% of CPU.

Hope this helps.
Rudolf

The backtraces don't seem to show anything interesting. When this happens, is the backtrace always the same, even after you leave gdb and re-attach?

I didn't try to reconnect and re-attach. I only did as instructed in comment #1. But as soon as this happens again, i will do as you say and do a second backtrace. 

Created attachment 20246 [details]
Another backtrace of kwin. First and second attach to the process.

These are two backtraces of one hanging kwin process. After taking the first
bt, i detached and reattached to the same process. I don't think, they differ.

Additional, i took a bt from the (looping) X process. But don't know, if this
is of interest or helps in any way.

The same happens here.
Suse 10.1, Radeon 9550, KDE 3.5.6
But in my case it also happens with the power management turned off.
Just leaving the computer for a longer period is enough to cause this behaviour.
And it doesn't seem to be related only to Suse.
Have a look at this: http://www.redhat.com/archives/fedora-list/2007-March/msg02531.html

I have exactly this problem too on Arch Linux. I'm running KDE 3.5.6 using nVidia's proprietary driver.

I'm also suspecting it happens mostly when the monitor resumes from standby but like others said not always reproducible.

I have another computer of similar hardware setup, but DPMS and monitor power saving are disabled. It never had this problem.

Although I really don't know if it's Xorg's, KDE's or nVidia's problem, but seeing comment #8 above, I guess it's not driver related.

Don't think it's nether related to the video driver as we see nVidia, Matrox and ATI in this bug report, nor seems it to be related to the X system, as we have different versions of it, too. 

As on comment #9, we should also exclude SuSE as the origin of the problem. 

Looks like the problem came up with KDE 3.5.5

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

I experience something very similar here.
At first I thought nvidia was responsible but I still get the problem without using the nvidia driver. But I never get it (on the same machine of course) when I use wmaker : it only happens while I use kde.

I use kubuntu 7.04 - kde 3.5.6 - nvidia FX 5200

Are you running Superkaramba by any chance? I used to have the same problem ,as you can see in comment #8, but managed to solve it by turning off some of the applets (I had about 8 at the time). I has been OK ever since.

Thank you.
Indeed I have stopped superkaramba 2 days ago and used my computer with no problem at all. I still get very high cpu usage by xorg from time to time but nothing abnormal I think. When I wrote comment #12, I would get a freeze in between a few minutes to 2 hours.

Please provide more details on how to reproduce the problem. How is one supposed to configure a newly created KDE account?

I confirm this problem.
Linux ghost 2.6.22-gentoo-r2-custom #8 SMP PREEMPT Sat Aug 18 18:02:19 CEST 2007 i686 AMD Athlon(tm) XP 3000+ AuthenticAMD GNU/Linux

lspci-> http://wklej.org/id/5d4571edc0

kdebase: 3.5.7-r3

I haven't been able to reproduce this problem since the upgrade to 3.5.7, however monitor doesn't always go standby when idle. It sometimes does and others times doesn't.

3 days without superkaramba... 0 Xorg deadlocks... :]

turned off several superkaramba applets and no lock ups for 8 days now

See comment #15. I'm sorry, but there's not much to do about this problem without having some useful information. If you can provide it, please reopen.

I've done some other test. This is what I've founded:

The problem is introduced by kwin 3.5.6. On my Gentoo I've forced the system to install kwin 3.5.5 (with kde 3.5.7), and the problem is disappeared. With kwin 3.5.6 the problem come back.

I've tried to downgrade only superkaramba, to previous versions, but with no success.

The problem is most frequent with applet with fast update time (1 second or less).

The problem is observable also without a screen saver. After few minutes (3-4) the CPU usage begins to grow, and after 10 minutes the PC is unusable, because Xorg (a process that running with root privileges) use 100% of CPU. My system is a single CPU Athlon XP 3000 (a 32bit single core CPU). It's possible that with multi CPU, or a recent PC, the system stay usable.

I don't know if is a bug of Xorg, superkaramba or kwin, but I know that without kwin, or with kwin <= 3.5.5, the problem disappear.

To reproduce this bug, use kwin >= 3.5.6, superkaramba and a lot of applet (clocks, system monitors, and some other with frequent updates), then leave your system, and come back after 30 minutes.

Thank you.

Recently I've installed openSuSE 10.3 on my new laptop, an AMD Athlon 64 X2, and with superkaramba enabled, this recent system, present the same problem, that I've observed on my AMD single core PC.

On SuSE, I've found that the problem of the 100% CPU usage by Xorg, is present also on 3.5.5 version of kwin.

Then I've reverted some of the SuSE patches, and I've found that the 3_5_BRANCH_kde_128648.diff introduce this "bug".

I've reverted some pieces of this patch, and I've found that the code modified in layers.cpp is probably the cause of this bug.

This is a patch to revert this code for kwin 3.5.7:

--- kwin/layers.cpp     2007-12-23 18:39:28.000000000 +0100
+++ kine/layers.cpp.sav 2007-12-23 18:39:55.000000000 +0100
@@ -117,11 +117,11 @@ void Workspace::updateStackingOrder( boo
         }
 #endif
     if( changed || propagate_new_clients )
-        {
+//        {
         propagateClients( propagate_new_clients );
-        if( active_client )
-            active_client->updateMouseGrab();
-        }
+//        if( active_client )
+//            active_client->updateMouseGrab();
+//        }
     }

 /*!

Created attachment 22663 [details]
Revert modification in layers.cpp

Without the code, removed by this patch, on my systems (Gentoo and openSuSE
10.3), the problem of 100% CPU usage by Xorg is disappeared.

Bump?

Now, at every update of kdebase3 package, I have to recompile the sources with the patch applied on all my systems.

At this time, I've tested this patch on Gentoo (with kde 3.5.8), openSuSE 10.3 x86, and openSuSE 10.3 x86_64 (both with kde 3.5.9).

*** This bug has been marked as a duplicate of 143255 ***