Summary: | KWin crash, when trying to use the new qml-based switcher | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Andreas Krohn <Hamburger1984> |
Component: | tabbox | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | arthur.souza12, g111, rvoinea, ssendilkumar |
Priority: | NOR | Flags: | mgraesslin:
ReviewRequest+
|
Version: | unspecified | ||
Target Milestone: | 4.9 Beta 1 | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
URL: | https://git.reviewboard.kde.org/r/105000/ | ||
Latest Commit: | http://commits.kde.org/kde-workspace/19c0fa5abd90a46de2ef6949a15de31111f930f4 | Version Fixed In: | 4.8.4 |
Sentry Crash Report: |
Description
Andreas Krohn
2012-01-03 11:05:28 UTC
any way to reproduce the crash? Being just under heavy load is rather difficult to test :-) well - that's the only situation I remember.. if I observe this behavior in other situations, i'll add another comment. 'heavy load' was 'building calligra and digikam' ;-) *** Bug 293031 has been marked as a duplicate of this bug. *** *** Bug 292589 has been marked as a duplicate of this bug. *** we need a reproducable way how to reproduce this crash. In case anyone is able to reproduce the crash, please provide steps on how to reproduce it. Thanks. I didn't observe this behavior in quite a while - maybe it was just an incompatibility with different qt/kms/intel libraries/drivers. I guess we can close this bug if noone else triggers this problem..?! thanks for the feedback. I think we can just keep it in this state and reopen it if it happens again :-) Btw I had seen the crash in the past, too. But had never been able to reproduce and haven't seen it for some weeks. Well, the crash does happen for me (using ubuntu backports) at least once a day. Sometimes it happens when using the hotkey function "Walk Through Desktops", sometimes I think it also happend with "Walk Through Windows". I do not know if it is always the same crash reason. The problem is that I cannot find a way to reproduce it. Sometimes I have the feeling that it happens after opening or maybe closing some windows or changing the stack order or something. Sometimes I think that it happens more often after working on one desktop for a bit longer or after unlocking the desktop lock after a break. But I do not know. I am very happen that kwin restarts and resets itself automatically afterwards, so I can continue to work. please have a look at bug #294534 it's just a wild guess, but do you (your distro) compile w/ -ftree-vectorize? Well, I am using ubuntu 10.10 with the KDE 4.8.1 backports at work. How can I find out if it was compiled with the -ftree-vectorize flag? Argh, sorry. it is today one year later than I thought. I am using ubuntu 11/10 (oneric or what the name is. well, version "O"). (In reply to comment #10) > Well, I am using ubuntu 10.10 with the KDE 4.8.1 backports at work. How can > I find out if it was compiled with the -ftree-vectorize flag? probably only by asking ubuntu / package maintainer - i can't see compiler flags listed in the .dsc *** Bug 299871 has been marked as a duplicate of this bug. *** *** Bug 300340 has been marked as a duplicate of this bug. *** Anyone experiencing this bug: what is your shortcut configuration for window and desktop switching? The shortcut I had set was Win+Tab for workspace cycle List, and Alt+tab for window-list current desktop. What I have noticed is that usually (heavy loaded conditions - my case when google-chrome browsing activity was running with multiple tabs or kdevelop or qtcreator code writing) it crashes. [Seems solved] - Recently I installed bumblebee based on the instructions here https://help.ubuntu.com/community/Asus_U31SD - Switched to OpenGL mode - Disabled OpenGL 2 Shaders & Use VSync from Desktop Effects (Advanced Settings) I find that recently it has not happened after that. ==== System : Kubuntu 12.04 upgraded from 11.10 Kernel 3.2.0-24-generic-pae (32bit) Asus : U31S Nvidia GT520 I think I found a way to reproduce the crash: 1. Configure both primary and secondary TabBox with different layouts 2. Use primary TabBox 3. Close a window, best the one which used to be active 4. Use secondary TabBox -> Crash Review Request on the way Git commit 05a3420175c88c7a106a245071d4bb3a75694e00 by Martin Gräßlin. Committed on 20/05/2012 at 15:52. Pushed by graesslin into branch 'master'. Use smart pointers to protect access to TabBoxClient Client holds a SharedPointer to the TabBoxClient and only provides access to a WeakPointer which is passed to TabBox. ClientModel is adjusted to hold a list of WeakPointers instead of the direct pointers. This fixes the following reproducable crash: 1. Configure both primary and secondary TabBox with different layouts 2. Use primary TabBox 3. Close a window, best the one which used to be active 4. Use secondary TabBox -> Crash The reason is that the ClientModel still contains the pointer to the deleted TabBoxClient in step 3 and while creating the layout access to the TabBoxClient is needed to get the Client's icon. By using the weak pointer it can be ensured that we don't try to dereference the deleted pointer and prevent the crash. Related: bug 285747, bug 237345 REVIEW: 105000 M +1 -4 kwin/client.cpp M +3 -3 kwin/client.h M +40 -28 kwin/tabbox/clientmodel.cpp M +1 -1 kwin/tabbox/clientmodel.h M +26 -14 kwin/tabbox/tabbox.cpp M +4 -4 kwin/tabbox/tabbox.h M +28 -6 kwin/tabbox/tabboxhandler.cpp M +6 -6 kwin/tabbox/tabboxhandler.h http://commits.kde.org/kde-workspace/05a3420175c88c7a106a245071d4bb3a75694e00 unfortunately backporting to 4.8 results in too many merge conflicts, so it's just a fix in 4.9 The reproducible steps, is that by writing a small test application. Or it relates to multiple-tabs in the APPLICATION kwin's titlebar (by grouping applications)? Hope I did not sound very silly in this question !! Git commit 19c0fa5abd90a46de2ef6949a15de31111f930f4 by Martin Gräßlin. Committed on 20/05/2012 at 15:52. Pushed by graesslin into branch 'KDE/4.8'. Use smart pointers to protect access to TabBoxClient Client holds a SharedPointer to the TabBoxClient and only provides access to a WeakPointer which is passed to TabBox. ClientModel is adjusted to hold a list of WeakPointers instead of the direct pointers. This fixes the following reproducable crash: 1. Configure both primary and secondary TabBox with different layouts 2. Use primary TabBox 3. Close a window, best the one which used to be active 4. Use secondary TabBox -> Crash The reason is that the ClientModel still contains the pointer to the deleted TabBoxClient in step 3 and while creating the layout access to the TabBoxClient is needed to get the Client's icon. By using the weak pointer it can be ensured that we don't try to dereference the deleted pointer and prevent the crash. Cherry-Picked from 05a3420175c88c7a106a245071d4bb3a75694e00 Related: bug 285747, bug 237345 FIXED-IN: 4.8.4 REVIEW: 105000 REVIEW: 105069 M +1 -4 kwin/client.cpp M +3 -3 kwin/client.h M +31 -22 kwin/tabbox/clientmodel.cpp M +1 -1 kwin/tabbox/clientmodel.h M +4 -2 kwin/tabbox/desktopitemdelegate.cpp M +19 -12 kwin/tabbox/tabbox.cpp M +4 -4 kwin/tabbox/tabbox.h M +28 -6 kwin/tabbox/tabboxhandler.cpp M +6 -6 kwin/tabbox/tabboxhandler.h http://commits.kde.org/kde-workspace/19c0fa5abd90a46de2ef6949a15de31111f930f4 |