|Summary:||kwin glxgears crash|
|Component:||aurorae||Assignee:||KWin default assignee <kwin-bugs-null>|
|Latest Commit:||http://commits.kde.org/kde-workspace/0fea5325de3a469dfb608c96d3bbeb896d031606||Version Fixed In:||4.9.0|
QnD (tm) patch
Slightly different patch
Fix Aurorae and Useractions
Description thardy01 2012-07-13 04:47:35 UTC
Comment 1 Martin Flöser 2012-07-13 05:54:22 UTC
* which window decoration are you using? * which graphics drivers are you using? * does the problem happens also when closing other OpenGL applications?
Comment 2 thardy01 2012-07-13 12:04:02 UTC
(In reply to comment #1) > * which window decoration are you using? Oxygen with all annimations off > * which graphics drivers are you using? nvidia-drivers-295.59 > * does the problem happens also when closing other OpenGL applications? Apperantly not.
Comment 3 thardy01 2012-07-13 12:21:24 UTC
(In reply to comment #2) > (In reply to comment #1) > > * which window decoration are you using? > Oxygen with all annimations off Sorry thats not true was using Dark-Translucent after switching back to default oxygen the crash has stoped and i dont have the mouse click lag. > > * which graphics drivers are you using? > nvidia-drivers-295.59 > > * does the problem happens also when closing other OpenGL applications? > Apperantly not.
Comment 4 Martin Flöser 2012-07-13 12:32:30 UTC
ok, then it makes more sense. Not that I understand it, but at least the QML part in the backtrace makes sense.
Comment 5 thardy01 2012-07-13 12:39:43 UTC
After further testing I now realise this crash and the mouse lag happens when using any window decoration that has trasparancy.
Comment 6 Thomas Lübking 2012-07-13 13:04:25 UTC
DecorationButton.qml case "X": // close decoration.closeWindow(); The DeclarativeView is still a GraphicsScene which cannot eat events at all, even if the sender is destroyed. There's nothing changed compared to old aurorae except that the eventloop escaping queued connection is no more present in th current implementation (afaics) You've to reimplement ::closeWindow (and likely maximize as well?) to QMetaObject::invokeMethod() some internal slot to call the KDecoration implementation on a QueuedConnection. ------- [assume unpostable comment about that aspect of QGraphicsScene here]
Comment 7 Martin Flöser 2012-07-13 13:57:03 UTC
> There's nothing changed compared to old aurorae except that the eventloop > escaping queued connection is no more present in th current implementation > (afaics) I have been using Aurorae now for > 1 month on both of my systems and never had a crash, neither when maximizing nor when closing the window. I assume that this nasty behavior of GraphicsScene is fixed and that something else triggered a crash here. E.g. I find the reference to libGL in Thread 2 most interesting...
Comment 8 Martin Flöser 2012-07-13 14:00:31 UTC
Very interesting: I can reproduce the crash with glxgears. No other window has ever crashed. Driver can be ruled out as a cause, it's radeon here.
Comment 9 Thomas Lübking 2012-07-13 14:11:25 UTC
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" after 73 requests (73 known processed) with 0 events remaining. Happens with or without any compositor and on either the raster or native graphicssystem. I'll try scheduling the event....
Comment 10 Thomas Lübking 2012-07-13 14:24:42 UTC
Created attachment 72498 [details] QnD (tm) patch Attached is a Quick and dirty patch, delaying the close by 125ms (recalling i've to cross more than one event loops, may be wrong though) - but i'm pretty sure the value can be narrowed. The patch adds a slot and a debug out since i'm not sure what QML calls when you reimplement the slot. -> The crash is no longer reproducible (still getting the XIO error though)
Comment 11 Thomas Lübking 2012-07-13 14:34:49 UTC
xio error is from glxgears - it's an emulation of the "heavy load" condition that used to cause the bug. nice testcase.
Comment 12 Martin Flöser 2012-07-13 14:36:09 UTC
Created attachment 72500 [details] Slightly different patch Attached another attempt by reimplementing the closeWindow slot. But: I still get a crash when using the close action of the useraction menu
Comment 13 Martin Flöser 2012-07-13 14:41:50 UTC
Created attachment 72501 [details] Fix Aurorae and Useractions added a queued connection also to useractions. Now following actions do not trigger a crash: * close button * useractions menu * alt+F4 * kwin script
Comment 14 Thomas Lübking 2012-07-13 14:58:55 UTC
"Ship It!" (Maybe add a comment to explain why the Op is scheduled) --- You don't have to convince me about this ;-P
Comment 15 Martin Flöser 2012-07-14 09:17:13 UTC
Git commit 0fea5325de3a469dfb608c96d3bbeb896d031606 by Martin Gräßlin. Committed on 14/07/2012 at 11:11. Pushed by graesslin into branch 'KDE/4.9'. Delay closing of a window by one event cycle This is an issue we already had in the past with Aurorae. When closing a window the graphics scene crashes because the deco gets destroyed before the code in the graphics scene finished the execution. With the port to QML this seemed to be fixed unless as it turns out it throws an XIO error on closing: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" This can be triggered using glxgears. Closing glxgears would reliable crash Aurorae. To circumvent this issue we have to delay the close by one event cycle using QMetaObject's invokeMethod with a Qt::QueuedConnection. This has also to be done in the useractions menu as the menu is still open when the window closes causing the same problem inside Aurorae. FIXED-IN: 4.9.0 Reviewed-By: Thomas Lüking M +10 -0 kwin/clients/aurorae/src/aurorae.cpp M +2 -0 kwin/clients/aurorae/src/aurorae.h M +1 -1 kwin/useractions.cpp http://commits.kde.org/kde-workspace/0fea5325de3a469dfb608c96d3bbeb896d031606
Comment 16 Thomas Lübking 2012-08-05 02:42:15 UTC
*** Bug 304579 has been marked as a duplicate of this bug. ***