Version: (using KDE 4.4.1) OS: Linux Installed from: Ubuntu Packages This is a pretty vague bug so i apologize. X will crash randomly when the battery is low, I have tested the same system with GNOME and there is no crash (tested about 8 suspend/resume cycles), so this is a kde issue. X actually crashes in the middle of suspend (i know this because once it crashed seconds before suspending. So X crashes, and then the system suspends and at resume: all data is (discovered to be)lost. This doesnt happen when the system is in performance mode and then suspended. So, to reproduce it in my case: drain the battery to ~%5. Put the system in "Xtreme Powersave". Click battery applet, click suspend. Doing this i have gotten 4 crashes in a row. I am trying to locate the exact setting in PowerDevil (since it seems to be powerdevil) that could be causing the crash, but it is going to take a while.
it seems to be after the power profile suspends compositing that the crash takes place. I can manually suspend compositing and everything's pretty, only when powerdevil does it. http://ubuntuforums.org/showthread.php?p=8955542#post8955542 has all the logs. this is a pretty serious bug, so i hope that it gets fixed. the issue effects NVIDIA 185, 190, and 195 (beta) drivers. It might also effect the 180 drivers.
I'm sorry to say, but if X crashes, it's an X problem, not a kwin problem. Most likely it is a driver issue and as NVIDIA is a binary driver, we cannot even look at it. Unfortunately I can't verify by looking at the log files as I don't have an account in ubuntuforums. I would recommend to disable the powerdevil feature to disable compositing if that is the cause.
the only "odd" thing in Powerdevil i can see is that it apparently queries compositing via dbus instead KWindowSystem::compositingActive() aside the slight overhead this may cause trouble when done while the session just ends (it's just a shot in the dark, though)
@Martin Gräßlin GNOME doesnt crash X. KDE does. I run GNOME with compiz btw. This is most definitely a kde issue, i know you cant do anything for the nvidia drivers, but KDE being opensource can be fixed. Normally I wouldnt make such a big deal about it, but this is users data we're talking here. @thomas thanks for considering this problem :) I really have no idea why what i observe is happening as i am not a coder, but it is happening. I have spent whole days dedicated to digging this issue up and i would really hate to have it sit and rot. Anything I can do to help collect more data just let me know. I will say that suspending compositing via the keyboard shortcut (alt f12) does not cause the crash. Maybe just have powerdevil use the same function that the shortcut uses?
Created attachment 41611 [details] xorg log at time of crash
Created attachment 41612 [details] kdm log at time of crash sorry i dont have xsession errors, if it is need i will reproduce the crash and post it.
sorry, but if X crashes, it is an X bug, not a kwin bug. We can only fix bugs in our code. The fact that the X or driver bug is not triggered in GNOME with Compiz does not imply that this is a bug in kwin. The X log does not contain any information which could help to identify the issue. It looks like not everything got logged (especially the crash is missing). I understand that you have data loss and that the situation is unpleasant, but we as KWin developers cannot solve this issue as we are not responsible for it.
upstream not fixed
(In reply to comment #4) > I will say that suspending compositing via the keyboard shortcut (alt f12) does > not cause the crash. Maybe just have powerdevil use the same function that the > shortcut uses? That's not possible (except for powerdevil faking a keypress... what's no good idea at all) and should not matter as well. You could however try to disable compositing the powerdevil way (instead of pressing f12) to see whether this is really the source. Enter a terminal (konsole) and fire (obviously while compositing is active) qdbus org.kde.kwin /KWin toggleCompositing Also please notice that X11 uses a client/server model. Clients are simply not supposed to be able to segfault it. This is why every X11 segfault (no matter how it's induced) is a bug in X11 (or a 3rd party driver - nvidia in this case) as the segfault appears to happen in libwfb and nvidia used to mess up this with their own variant for compatibillity reasons, please check your distro for the source of "/usr/lib/xorg/modules/libwfb.so" and "/usr/lib/xorg/modules/" for similar libraries as a very wild shot into the dark, set "UseEvents" "true" in the device section of xorg.conf and restart X (if it doesn't help, remove the setting again!)
@Thomas thanks for explaining how X11 clients are unable to segfault x, i did not understand this. I will try all the tests you suggested, thanks. thanks also for the tip about libwfb.so, maybe ill collect enough info to report a bug to nvidia. Is there any chance of warning users about this bug? Or am I the only one who seems to be having this issue? @Martin Thomas explained for me how this cant be a kwin bug. I apologize for my overzealousness :| . I want to say that you guys are doing an awesome job on kwin :)
you can btw. try adding xorg.conf Section "Module" Disable "wfb" EndSection and restart X11 - this might however cause artefacts or even real trouble when changing to a VTx (ctrl+alt+f1) - so be careful when doing this (maybe the X server just refuses to start at all)