Summary: | libreoffice kwin crash on startup after update | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | MikeC <mike.cloaked> |
Component: | compositing | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED NOT A BUG | ||
Severity: | crash | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
Screenshot showing libreoffice crash in KDE
xorg log at the time of rebooting after LO crash Output of qdbus-qt4 org.kde.kwin /KWin supportInformation > kwin-support-info |
Description
MikeC
2014-04-13 13:03:39 UTC
Created attachment 86068 [details]
Screenshot showing libreoffice crash in KDE
- What makes you believe that this is a KDE, let alone KWin issue? - Define " KDE/X freezes" - can you still move the pointer, does suspending the compositor (Shift+Alt+F12) "unfreeze" KDE/X11 - does this also happen with disabled compositing when starting LO? - please attach /var/log/Xorg.0.log after such freeze (it's renamed to /var/log/Xorg.1.log if you restart X11 inbetween) - can you (from VT1) $ export DISPLAY=:0 $ xprop or does it say the mouse was grabbed? - please provide the output of "qdbus org.kde.kwin /KWin supportInformation" (freeze condition is not required) - does this also happen if you disable HW acceleration in LO? Thanks for your feedback Thomas. I was not sure where the relevant problem lay and did not know how to find if it was in kwin or the libreoffice package itself, but the "freeze" is in two stages. First the mouse initially does move, but nothing in the Libreoffice window responds to mouse clicks, apart from the "close cross" in the Libreoffice window with a delay. However if once the popup occurs after that "close cross" is clicked, then leaving the system then gives a real freeze and then the mouse cannot be used to select anything at all. The kernel is still running at that point, and I could ssh in and initiate a reboot. I will attach the /var/log/Xorg.0.log.old file that was relevant at the time of that last crash. I will try the xprop command from a separate VT the next time I have this crash. The command qdbus org.kde.kwin /KWin supportInformation yields: $ qdbus org.kde.kwin /KWin supportInformation qdbus: could not exec '/usr/lib/qt/bin/qdbus': No such file or directory I have not tried to disable HW acceleration in LO itself - but I will look at that and test. Created attachment 86070 [details]
xorg log at the time of rebooting after LO crash
I have now also tested by running LO using the command line "libreoffice --writer" and this also generates the same crash as running from the KDE menu. So I am wondering if this is a bug in the package libreoffice-kde4 4.2.3-2 rather than kwin. Certainly prior to version libreoffice-kde4 4.2.3-1 there was no crash in the same circumstances. Given that this bug may be in the libreoffice packages I have submitted a report at https://www.libreoffice.org/bugzilla/show_bug.cgi?id=77400 (In reply to comment #3) > but nothing in the Libreoffice window responds to mouse clicks The process likely just hangs somewhere (LO bug) - other windows (and the titlebars) do still respond, as I take it? > then leaving > the system then gives a real freeze and then the mouse cannot be used to > select anything at all. Could it be that the screesaver/locker kicks in (and fails for whatever reason)? Do you have a screesaver/locker timeout configured ("kcmshell4 screensaver") > I will attach the /var/log/Xorg.0.log.old Does not look like any server error. X11 itself does not seem to hang. > The command qdbus org.kde.kwin /KWin supportInformation yields: *sigh* - try "qdbus-qt4" instead (sorry, should have known) (In reply to comment #4) > Certainly prior to version libreoffice-kde4 4.2.3-1 It's possible that the desktop integration module causes an infinite loop or a dead input grab. You can "export SAL_USE_VCLPLUGIN=gen" http://ask.libreoffice.org/en/question/3078/choose-gui-toolkit-for-lo-session/ The screensaver is not involved as far as I know. I have now run the command: $ qdbus-qt4 org.kde.kwin /KWin supportInformation > kwin-support-info and will attach the file shortly. Created attachment 86072 [details]
Output of qdbus-qt4 org.kde.kwin /KWin supportInformation > kwin-support-info
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=77400#c2 says it's a bug in the LO kde4 integration module. OK - hopefully we will see some progress on the LO bug report referenced in c6 and c10 above. since LO apparently stalls, you should be able to gdb attach to it and dump a backtrace ("bt") about the dead mouse "after a while": it's possible that LO grabs it. In this case, just killing LO from VT1 or ssh would also release the input. Alternatively (if the input is not grabbed), the servers eyent queue might be flooded (but the Xorg.0.log doesn't look like that) |