Summary: | kwin glxgears crash | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | thardy01 |
Component: | aurorae | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | bernd_schmidt_sh, zubiart |
Priority: | NOR | ||
Version: | 4.8.97 | ||
Target Milestone: | 4.9.0 | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | http://commits.kde.org/kde-workspace/0fea5325de3a469dfb608c96d3bbeb896d031606 | Version Fixed In: | 4.9.0 |
Attachments: |
QnD (tm) patch
Slightly different patch Fix Aurorae and Useractions |
Description
thardy01
2012-07-13 04:47:35 UTC
* which window decoration are you using? * which graphics drivers are you using? * does the problem happens also when closing other OpenGL applications? (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. (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. ok, then it makes more sense. Not that I understand it, but at least the QML part in the backtrace makes sense. After further testing I now realise this crash and the mouse lag happens when using any window decoration that has trasparancy. 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] > 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...
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. 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.... 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)
xio error is from glxgears - it's an emulation of the "heavy load" condition that used to cause the bug. nice testcase. 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
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
"Ship It!" (Maybe add a comment to explain why the Op is scheduled) --- You don't have to convince me about this ;-P 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 *** Bug 304579 has been marked as a duplicate of this bug. *** *** Bug 309909 has been marked as a duplicate of this bug. *** |