Version: unspecified (using KDE 4.5.0) OS: Linux I have a two monitor layout, with a LCD left of my laptop monitor. Activating the desktop grid plugin of kwin works perfectly, unless I move an application window from one (of four) desktop to another. In this case, the application segfaults immediately. It seems to be independent of the actual application. Reproducible: Always Steps to Reproduce: Activate "external monitor left of screen"-layout with randr. Start desktop grid effect. Move a window from one desktop to another. Actual Results: The application crashes due to a segmentation fault. Expected Results: The application should not have crashed but moved from one desktop to another.
do you mean the client (ie. eg. konqueror, dolphin, kwrite, amarok, etc.) crashes? please attach a backtrace (developer inforamtion/details - there should be some dialog)
Yes, the client crashes. But since this only happens with kwin's desktop grid, I thought I'd post it as a kwin bug instead of a seperate bug for every client concerned. But now I'm really confused: I have this bug since a few versions of KDE 4 and always looked for the thing that made this bug reproducable. This morning I could reproduce this bug by just opening an arbitrary application and moving it using the grid effect. Now, after a restart, everything seems to work just fine, except for a konqueror session that auto-started. To sum it up: I cannot see any reproducable behaviour here. Sometimes all programs crash, sometimes just very specific ones (konqueror is always a candidate). Sometimes this only happens with a two-monitor layout, sometimes it happens without the external monitor attached. And sometimes everything just works perfect (like now). I'll provide you with a backtrace as soon as possible. I also have problems with occasional x.org-crashes (in fact this problem is responsible for the restart mentioned above), see https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/585647 This also started to happen a few KDE Versions ago, but I don't know if it started with the same version as the grid effect bug. Could these two bugs maybe somehow related (actually, I don't think so, but just in case...)?
Ok, I've got something: Attached below, you'll find the backtrace of a crashed kate-session. But this bug also occurs with non-KDE applications. Eclipse for example produces the following error (when started in a console before): ~$ eclipse The program 'Eclipse' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 19594 error_code 11 request_code 53 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) ~$ To get these crashes, it seems I have to suspend and resume the laptop. Could that be the cause?
Created attachment 51234 [details] backtrace of a kate crash when moving kate using the grif effect
i assume you have to move the window to the other screen/monitor? seems the pixmap does not get associated with the new screen/display when doing so... (the kate trace indicates this: there's ultimately an XRenderComposite at the end and eclipse results in a BadAlloc ...) from the fact that it happens in Qt applications as well as in Gtk+/Java ones (Eclipse) and you may have to suspend/resume the machine and also you X11 is instable, this /should/ be a driver bug, but i wouldn't say for sure (what if you cross screens w/o any effect?)
Probably bug 230490.
Actually, this bug ONLY appears, when I move the windows on the very same physical screen to another virtual screen (sorry for not pointing that out earlier). Moving without the grid plugin works in any case, i.e. between the virtual screens and the physical ones. For that I use the mouse wheel on the title bar of the respective window.
I encounter this bug as well. As soon as I upgraded to KDE 4.5.0 yesterday I started noticing this problem. I upgraded to 4.5.1 today and the problem persists. I'm running Kubuntu with the KDE 4.5.1 packages on Linux 2.6.32-24-generic. I'm using a dual-monitor setup with fglrx as the xorg video driver. I have not checked to see if this problem exists with a single monitor setup. I'm using OpenGL compositing, but this also happens with XRender compositing. I get the same type of backtrace posted by Mat for QT applications, and non-QT applications spit out BadAlloc and other nasty errors which I can see by starting them from a terminal. Sometimes the window just disappears and the application continues running. For me, the buggy behaviour seems to depend on the state of the window enclosing the application, and I can divide it into three categories: 1 - an application's window is not maximized and it has not been moved from the window manager's default placement: If you try to move it from one virtual desktop to another it will crash immediately. This happens even if you maximize the window then minimize it again. 2 - an applications window is not fully maximized and it has been moved away from the window manager's default placement (even if it's back to the same location as the default placement): Here the window will move but will only stay within one monitor. When I try dragging it to the other monitor it will very quickly render a flash of the window on the other monitor, but it pops over to the equivalent desktop on the first monitor. 3 - an application's window is fully maximized: Here it behaves properly and can move to any desktop on any screen, as expected. This also works if the application starts up fully maximized. However, if you start the application, maximize it, move it to another desktop, unmaximize it, then try moving it to another desktop without first moving it away from the window manager's default placement, it will crash immediately. So to summarize: - to prevent the application from crashing, it must be moved away from the window manager's default placement except when it is maximized. - to move to any desktop on any screen, the window must be maximized. I hope this helps in tracking down the bug.
I haven't tried all categories mentioned by bisrcacuo yet, but I can confirm many of them. He describes the situation pretty well. I don't know if this is actually a bug or an intended change, but since a few versions of KDE moving windows with the grid effect does not really move them, but only changes the screen they appear in. To make this clearer: Before, in the grid view I could freely move any window anywhere (even on the same virtual screen) by just grabbing it and moving the mouse. Now, the window stays on the exact same place until the mouse moves into the area of another (virtual) screen. Then, the respective window jumps to the same place again, just on the screen where the mouse is. Is this behaviour intended? If not, is it maybe related to the bug?
I'm encountering this bug as well on ArchLinux, Nvidia proprietary driver (256.xx version), KDE 4.5.1, twinview setup
I have the same bug (or a very similar one), but for one difference: I am not using a two-monitor layout -- I am using a Lenovo X200 Tablet with Intel graphics (i915) and only the internal LCD display. This is on Kubuntu 10.04, updated to KDE 4.5.1. I also note the behavior mentioned in Comment 9: "since a few versions of KDE moving windows with the grid effect does not really move them, but only changes the screen they appear in." I think that this bug appeared around the same time that this behavior changed, although I am not positive.
this is likely a different bug. w/o using the present windows proxy effect - the windows do no more "move" but just swap desktops - *sometimes* "disappear", they do not segfault but just drop from compositing (suspending composition will bring them on screen - top left corner & minimal size?!)
*** This bug has been marked as a duplicate of bug 230490 ***