| Summary: | Screen freezed when trying to get desktop grid from desktop corner (3d effect) | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Christophe Larsonneur <clarsonneur> |
| Component: | effects-desktop-grid | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | elvis.angelaccio, flyos, laggerfromrussia, mabo, unsuspicious.fakename+kdebugs, xeno |
| Priority: | NOR | Keywords: | drkonqi |
| Version: | 5.7.3 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/kwin/4348cd56834cb17da5aa9d95d16ddc27bf39e0e6 | Version Fixed In: | 5.15.0 |
| Sentry Crash Report: | |||
|
Description
Christophe Larsonneur
2016-09-14 15:41:32 UTC
Unfortunately the backtrace is lacking debug symbols. We don't see where in the code the crash happens. If able please install debug symbols. From what we see the crash happens inside Qt when trying to create a window and triggers a terminating X error. If we have the line numbers we can check what goes wrong and forward the bug to Qt. ok. I will install debuginfo stuff then. I will try to generate a coredump on the freezed process, before it crash. Because this is the issue I have. Thank you Martin. I have kwin freezing again. Thank gdb, I found it is looping at /usr/src/debug/kwin-5.7.3/effects/presentwindows/presentwindows.cpp:1320 I noticed also that renderer is set to OpenGL 3.1 It looks like OpenGL 2.0 is a little bit faster in term of effects. (or more smooth) I'm wondering if my issue is not coming from the OpenGL version 3.1. (with nvidia driver) I switched to 2.0 and I will see if the issue still happen or not. > /usr/src/debug/kwin-5.7.3/effects/presentwindows/presentwindows.cpp:1320
It's looping there? That one should exit. But we have had reports about that before.
Can you check what kind of windows you have and see whether there is some window responsible for it. Or some layout?
ok. Interesting. How can I check if there is one window or layout doing the freeze? Is there any way to get them? How do you suggest me to identify those windows? > How do you suggest me to identify those windows?
Maybe xwininfo -tree?
Hi, I think I found the window that break the 3d effect and causing kwin to freeze: hp myroom (java app) Do you think that kwin could do something to avoid this kind of freeze because of a window? (In reply to Christophe Larsonneur from comment #7) > Hi, > > I think I found the window that break the 3d effect and causing kwin to > freeze: > hp myroom (java app) where can one get this app? > > Do you think that kwin could do something to avoid this kind of freeze > because of a window? yes, once we have a way to reproduce, we can investigate and fix it. This is where I downloaded the hp myroom tool: https://www.myroom.hpe.com/Download FYI: I stopped the hp myroom tool and all were good until the time I used it back! So, another freeze occurs and then, I decided to kill hpmyroom process. But kwin did not recover from his freeze state. The process is still at 100% CPU, at this time. As soon as I have the final coredump, I can send it here also. I don't know if it can help you guys. Just tell me. If you need anything else from my side, do not hesitate. I have a similar issue. Here (Intel graphics, Xorg session) kwin freezes only when I trigger the desktop grid _with_ a second monitor attached. Though it doesn't always happen, just randomly. Same problem here, don't have any "weird windows" as far as I can tell. Did you use some sort of debugging trick to find out which window is the cause or just trial and error? *** Bug 375268 has been marked as a duplicate of this bug. *** Same here, Fedora/Intel IvyBridge gfx. Can't remember when it started exactly but somwhere around Plasma 5.4. Really can't get what trigger the bug. One day I can trigger it almost every time and then it can work flawlessly for weeks. Usual running apps are Firefox, Qupzilla, Kontact, Konsole and Kate. Also Skype, qTox, Konversation and Amarok in tray. Kwin usually uses OGl 3.1 renderer, but it also hapend when using OGL 2.0 Looks like I found new way to workaround this issue. I tried to send SIGABRT (pkill -6 kwin) and kwin continue normal work after little screen reload. Way with --replace breaks windows title size for me (make them huge). Git commit 30ad58f559aa0cfc5dba649be387578481e8db32 by Vlad Zagorodniy, on behalf of Erik Kurzinger. Committed on 20/10/2018 at 15:37. Pushed by vladz into branch 'master'. [effects/presentwindows] Avoid potential freeze during fill-gaps Summary: When using the natural layout algorithm with the fill-gaps option, a small error (less than one) is introduced in windows' aspect ratio each time they are enlarged due to floating-point roundoff. Currently, the algorithm computes the width and height enlargement factors and then attempts to enlarge in each of the four possible directions, repeating until it can't enlarge any windows any further. Hence, this aspect ratio error can be multiplied by up to four. Especially for small, long, and narrow windows, this can result in a total error of greater than one by the end of that loop iteration. If this occurs, on subsequent iterations the height enlargement factor might then be computed as negative violating some of the core assumptions of the algorithm and resulting in the loop iterating endlessly until one of the window dimensions overflows, freezing the program for up to several minutes. To fix this, the height enlargement factor should be re-computed based on the new width each time the window is enlarged, ensuring the error introduced in the aspect ratio never exceeds one. Related: bug 364709, bug 380865 FIXED-IN: 5.15.0 Test Plan: The most reliable way to reproduce the freeze seems to be to activate the desktop-grid effect while a tool-tip window is fading in. Ensure desktop-grid is configured to use present windows, and that present windows is configured to use the natural layout algorithm with the fill gaps option selected. The freeze is still intermittent, but using this method should be able to be triggered within about 10 tries without this fix. After applying the fix, the freeze has never been observed. Reviewers: #kwin, zzag Reviewed By: #kwin, zzag Subscribers: graesslin, kwin, zzag Tags: #kwin Differential Revision: https://phabricator.kde.org/D16278 M +15 -3 effects/presentwindows/presentwindows.cpp https://commits.kde.org/kwin/30ad58f559aa0cfc5dba649be387578481e8db32 Git commit 4348cd56834cb17da5aa9d95d16ddc27bf39e0e6 by Vlad Zagorodniy, on behalf of Erik Kurzinger. Committed on 28/10/2018 at 22:02. Pushed by vladz into branch 'Plasma/5.12'. [effects/presentwindows] Avoid potential freeze during fill-gaps Summary: When using the natural layout algorithm with the fill-gaps option, a small error (less than one) is introduced in windows' aspect ratio each time they are enlarged due to floating-point roundoff. Currently, the algorithm computes the width and height enlargement factors and then attempts to enlarge in each of the four possible directions, repeating until it can't enlarge any windows any further. Hence, this aspect ratio error can be multiplied by up to four. Especially for small, long, and narrow windows, this can result in a total error of greater than one by the end of that loop iteration. If this occurs, on subsequent iterations the height enlargement factor might then be computed as negative violating some of the core assumptions of the algorithm and resulting in the loop iterating endlessly until one of the window dimensions overflows, freezing the program for up to several minutes. To fix this, the height enlargement factor should be re-computed based on the new width each time the window is enlarged, ensuring the error introduced in the aspect ratio never exceeds one. Related: bug 364709, bug 380865 FIXED-IN: 5.15.0 Test Plan: The most reliable way to reproduce the freeze seems to be to activate the desktop-grid effect while a tool-tip window is fading in. Ensure desktop-grid is configured to use present windows, and that present windows is configured to use the natural layout algorithm with the fill gaps option selected. The freeze is still intermittent, but using this method should be able to be triggered within about 10 tries without this fix. After applying the fix, the freeze has never been observed. Reviewers: #kwin, zzag Reviewed By: #kwin, zzag Subscribers: graesslin, kwin, zzag Tags: #kwin Differential Revision: https://phabricator.kde.org/D16278 M +15 -3 effects/presentwindows/presentwindows.cpp https://commits.kde.org/kwin/4348cd56834cb17da5aa9d95d16ddc27bf39e0e6 |