| Summary: | Plasma crashed & restarted after reboot | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Pekka <spamtrap_kde> |
| Component: | general | Assignee: | David Edmundson <kde> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | crash | CC: | a.diewald, bhush94, johan.reitan, plasma-bugs |
| Priority: | NOR | Keywords: | drkonqi |
| Version: | 5.4.2 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Pekka
2015-11-04 07:25:25 UTC
*** Bug 354203 has been marked as a duplicate of this bug. *** Thanks, I've been hoping to get one of these crashes with a line number in Qt.
xcb_translate_coordinates_cookie_t cookie =
xcb_translate_coordinates(xcb_connection(), xcb_window(), m_screen->root(),
pos.x() * dpr, pos.y() * dpr);
xcb_translate_coordinates_reply_t *reply =
xcb_translate_coordinates_reply(xcb_connection(), cookie, NULL); <---- here
if (reply) {
ret.setX(reply->dst_x / dpr);
ret.setY(reply->dst_y / dpr);
free(reply);
}
wait, that doesn't match up at all.... Fedora must have a patched Qt. If it's any help.. here are currently installed qt5 packages with version numbers: [mcfish@... ~]$ rpm -qa | grep -i qt5- | sort dbusmenu-qt5-0.9.3-0.10.20150604.fc22.x86_64 dbusmenu-qt5-debuginfo-0.9.3-0.3.20140604bzr.fc22.x86_64 libkscreen-qt5-5.4.2-1.fc22.x86_64 libkscreen-qt5-debuginfo-5.4.2-1.fc22.x86_64 PackageKit-Qt5-0.9.5-1.fc22.x86_64 phonon-qt5-4.8.3-3.fc22.x86_64 phonon-qt5-backend-gstreamer-4.8.2-3.fc22.x86_64 polkit-qt5-1-0.112.0-3.fc22.x86_64 polkit-qt5-1-debuginfo-0.103.0-4.20130415gitbac771e.fc22.x86_64 poppler-qt5-0.30.0-3.fc22.x86_64 qca-qt5-2.1.0-14.fc22.x86_64 qt5-qtbase-5.5.0-18.fc22.x86_64 qt5-qtbase-common-5.5.0-18.fc22.noarch qt5-qtbase-debuginfo-5.5.0-18.fc22.x86_64 qt5-qtbase-gui-5.5.0-18.fc22.x86_64 qt5-qtdeclarative-5.5.0-3.fc22.x86_64 qt5-qtdeclarative-debuginfo-5.5.0-3.fc22.x86_64 qt5-qtgraphicaleffects-5.5.0-2.fc22.x86_64 qt5-qtlocation-5.5.0-3.fc22.x86_64 qt5-qtlocation-debuginfo-5.5.0-3.fc22.x86_64 qt5-qtmultimedia-5.5.0-3.fc22.x86_64 qt5-qtquickcontrols-5.5.0-3.fc22.x86_64 qt5-qtscript-5.5.0-3.fc22.x86_64 qt5-qtscript-debuginfo-5.5.0-3.fc22.x86_64 qt5-qtsensors-5.5.0-3.fc22.x86_64 qt5-qtsensors-debuginfo-5.5.0-3.fc22.x86_64 qt5-qtsvg-5.5.0-3.fc22.x86_64 qt5-qtsvg-debuginfo-5.5.0-3.fc22.x86_64 qt5-qttools-5.5.0-4.fc22.x86_64 qt5-qttools-common-5.5.0-4.fc22.noarch qt5-qttools-debuginfo-5.5.0-4.fc22.x86_64 qt5-qttools-libs-designer-5.5.0-4.fc22.x86_64 qt5-qtwebkit-5.5.0-4.fc22.x86_64 qt5-qtwebkit-debuginfo-5.5.0-4.fc22.x86_64 qt5-qtx11extras-5.5.0-2.fc22.x86_64 qt5-qtx11extras-debuginfo-5.5.0-2.fc22.x86_64 qt5-qtxmlpatterns-5.5.0-3.fc22.x86_64 qt5-qtxmlpatterns-debuginfo-5.5.0-3.fc22.x86_64 If this bug is the same as #354203, I can add information about another condition that triggers this crash. I am running a gentoo box with plasma 5.4.2 and QT 5.5.1. I have a dual-screen setup consisting of integrated display (tablet/laptop) and an external monitor (main screen) connected via display link. As soon as the external monitor falls asleep, plasmashell shows some weird behaviour, such that the widgets and the background is only shown on the internal display, while the task bar is still located on the external screen (black background). When the external monitor sleeps for second time I can observe the behaviour detailed in #354203 that is a crash of plasmashell and kdeinit5. Then, after closing the crashreport dialogs I am thrown back to the login screen (the tty is visible for a short time) or plasma restarts. This is very annoying, as unsaved work can be lost easily. I think this issue is closely related to this bug: https://bugreports.qt.io/browse/QTBUG-42985. I could not observe this behaviour with QT5.4.2. Unfortunately, some dependencies require QT>=5.5. Regards, Alex So, I did launch rpmbuild for the fedora qtbase package, and this is the problematic part (in handleClientMessageEvent):
...
else if (event->data.data32[0] == atom(QXcbAtom::WM_TAKE_FOCUS)) {
connection()->setTime(event->data.data32[1]);
relayFocusToModalWindow();
return;
} else if (event->data.data32[0] == atom(QXcbAtom::_NET_WM_PING)) {
if (event->window == xcbScreen()->root()) <--------- HERE (line 1940, 5.5 git branch: 1942)
return;
xcb_client_message_event_t reply = *event;
...
In the qtbase project, 5.5 branch on git, this is line 1942 in qxcbwindow.cpp. I assume that xcbScreen() is null at this point and causes the crash. I will inspect this evening.
Conversely to my previous suspicion, this is not covered in https://bugreports.qt.io/browse/QTBUG-42985.
Regards,
Alex
Thanks I forgot to update this bug report, but I your thinking matches what I found. Other message handling has null xcbScreen() checks, so it shouldn't be too controversial to get in. Ideally shouldn't just ignore a ping, as the WM might then just close us anyway. It'll be better than crashing though I suppose. For Qt 5.6 there's talk about windows always having a fake screen rather than a null pointer, so that also implicitly solves our problem. Thanks for the update! I have re-compiled qtbase/qtcore with the patch but I still get the same behaviour and a crash in the very same method. Yesterday evening, I struggeled with getting the debug symbols in for the binaries and libraries that are needed for a meaningful backtrace. I still need to solve an issues with sddm (https://github.com/sddm/sddm/issues/506) not starting due to debug symbols, but I guess I can provide more information this evening. Should this bug reopened (same problem) or shall I create a new one (different cause of the problem) once I have the "good" backtrace? You may call me stupid. Gentoo packagers split qtbase in two ebuilds: qtcore and qtgui. I applied the patch to the wrong one. I can confirm now that the issue is solved. |