| Summary: | Reproducible crash of Kate and Konqueror in KActionConflictDetector::eventFilter | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kxmlgui | Reporter: | Sandeep Kumar <kumar> |
| Component: | general | Assignee: | David Faure <faure> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | crash | CC: | christoph, codie.rae, faure, kde, kdebugs, marcelo.jimenez, nate |
| Priority: | NOR | Keywords: | drkonqi |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Sandeep Kumar
2017-06-29 10:01:32 UTC
This part of the backtrace looks like same issue as bug 384563 [KCrash Handler] #6 0x00000000010c2070 in () #7 0x00002b3515f2d3c9 in QMetaObject::cast(QObject*) const () at /usr/lib64/libQt5Core.so.5 #8 0x00002b351249f46f in () at /usr/lib64/libKF5XmlGui.so.5 #9 0x00002b3515f24d6d in QCoreApplicationPrivate::sendThroughApplicationEventFilters(QObject*, QEvent*) () *** Bug 384563 has been marked as a duplicate of this bug. *** *** Bug 387789 has been marked as a duplicate of this bug. *** Like in bug 384563, we seem to crash in KActionConflictDetector, perhaps like in the other bug in: kactionconflictdetector.cpp:44 *** Bug 381814 has been marked as a duplicate of this bug. *** *** Bug 388987 has been marked as a duplicate of this bug. *** Confirmed crash of konqueror as described in bug #384650. Same konqueror version as in bug #384650, but Leap 42.3. No need to restart the system at all, a simple restart of konqueror "fixes" the problem. After a restart it doesn't matter if you restore the old windows or not, closing a view always crashes konqueror again. kate-17.12.2-2.fc27.i686 Could not reproduce. It might be helpful for those tracking konqueror Bug 384563 to create a bisect of kate between 16.08.2 and 17.12.2 to see how it was solved. Actually, just tested: git checkout Applications/16.08 of kate, also with: qt5-qtbase-devel-5.9.6-4.fc27.i686 (same qt I tested konq with), and I cannot reproduce the crash on closing a view in kate. Is it possible that Bug 384563 is not a duplicate of this? The crash can be reproduced with one of the konqueror unittests:
konqviewmgrtest testPopupNewWindow
It crashes in KActionConflictDetector when the mainwindow gets destroyed.
Unfortunately valgrind is not usable there because of WebEngine.
ASAN just says null pointer.
=
==20566==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f6d71ccbfa0 bp 0x7ffcac0881c0 sp 0x7ffcac0881b0 T0)
==20566==The signal is caused by a READ memory access.
==20566==Hint: address points to the zero page.
#0 0x7f6d71ccbf9f in QMetaObject::cast(QObject const*) const /d/qt/5/kde/qtbase/src/corelib/kernel/qmetaobject.cpp:374
#1 0x7f6d71ccbf74 in QMetaObject::cast(QObject*) const /d/qt/5/kde/qtbase/src/corelib/kernel/qmetaobject.cpp:363
#2 0x7f6d7801e15e in QAction* qobject_cast<QAction*>(QObject*) /d/qt/5/inst/include/QtCore/qobject.h:508
#3 0x7f6d7801e15e in KActionConflictDetector::eventFilter(QObject*, QEvent*) /d/kde/src/5/frameworks/kxmlgui/src/kactionconflictdetector.cpp:45
#4 0x7f6d71cc28c1 in QCoreApplicationPrivate::sendThroughApplicationEventFilters(QObject*, QEvent*) /d/qt/5/kde/qtbase/src/corelib/kernel/qcoreapplication.cpp:1203
#5 0x7f6d72f1e799 in QApplicationPrivate::notify_helper(QObject*, QEvent*) /d/qt/5/kde/qtbase/src/widgets/kernel/qapplication.cpp:3674
#6 0x7f6d72f1e70e in QApplication::notify(QObject*, QEvent*) /d/qt/5/kde/qtbase/src/widgets/kernel/qapplication.cpp:3653
#7 0x7f6d71cc262d in QCoreApplication::notifyInternal2(QObject*, QEvent*) /d/qt/5/kde/qtbase/src/corelib/kernel/qcoreapplication.cpp:1095
#8 0x7f6d71cc2f79 in QCoreApplication::sendEvent(QObject*, QEvent*) /d/qt/5/kde/qtbase/src/corelib/kernel/qcoreapplication.cpp:1490
#9 0x7f6d72f18e83 in QApplication::setActiveWindow(QWidget*) /d/qt/5/kde/qtbase/src/widgets/kernel/qapplication.cpp:2043
#10 0x7f6d72f578d3 in QWidgetPrivate::deactivateWidgetCleanup() /d/qt/5/kde/qtbase/src/widgets/kernel/qwidget.cpp:2480
#11 0x7f6d72f66a04 in QWidgetPrivate::hide_sys() /d/qt/5/kde/qtbase/src/widgets/kernel/qwidget.cpp:8270
#12 0x7f6d72f667d7 in QWidgetPrivate::hide_helper() /d/qt/5/kde/qtbase/src/widgets/kernel/qwidget.cpp:8213
#13 0x7f6d72f67075 in QWidgetPrivate::setVisible(bool) /d/qt/5/kde/qtbase/src/widgets/kernel/qwidget.cpp:8418
#14 0x7f6d72f66b8b in QWidget::setVisible(bool) /d/qt/5/kde/qtbase/src/widgets/kernel/qwidget.cpp:8320
#15 0x7f6d72f666fb in QWidget::hide() /d/qt/5/kde/qtbase/src/widgets/kernel/qwidget.cpp:8187
#16 0x7f6d72f67774 in QWidgetPrivate::close_helper(QWidgetPrivate::CloseMode) /d/qt/5/kde/qtbase/src/widgets/kernel/qwidget.cpp:8547
#17 0x7f6d72f54a0d in QWidget::~QWidget() /d/qt/5/kde/qtbase/src/widgets/kernel/qwidget.cpp:1626
#18 0x7f6d730d7f6d in QMainWindow::~QMainWindow() /d/qt/5/kde/qtbase/src/widgets/widgets/qmainwindow.cpp:377
#19 0x7f6d7803c412 in KMainWindow::~KMainWindow() /d/kde/src/5/frameworks/kxmlgui/src/kmainwindow.cpp:399
#20 0x7f6d90fa8b47 in KonqMainWindow::~KonqMainWindow() /d/kde/src/5/kde/applications/konqueror/src/konqmainwindow.cpp:350:1
At the time when QApplication::setActiveWindow(nullptr) is called, QApplicationPrivate::focus_widget is a dangling pointer.
With some qDebugs I could see that it was a WebEngineView earlier (webenginepart's QWebEngineView subclass), and that it indeed got deleted meanwhile.
QDEBUG : ViewMgrTest::testPopupNewWindow() WebEngineView::WebEngineView WebEngineView(0x55e6295c0190)
QDEBUG : ViewMgrTest::testPopupNewWindow() QApplicationPrivate::setFocusWidget focus_widget= WebEngineView(0x55e6295c0190)
QDEBUG : ViewMgrTest::testPopupNewWindow() checkSecondWindowHasOneTab WebEngineView(0x55e6295c0190)
QDEBUG : ViewMgrTest::testPopupNewWindow() WebEngineView::~WebEngineView WebEngineView(0x55e6295c0190)
QDEBUG : ViewMgrTest::testPopupNewWindow() QApplication::setActiveWindow sending event to focus_widget= 0x55e6295c0190 <<< DANGLING
Definitely looks like a Qt bug.
The deleted focus-widget had a focus proxy, QtWebEngineCore::RenderWidgetHostViewQtDelegateWidget But QApplicationPrivate::focus_widget is the WebEngineView, not its focus proxy. Due to that, QWidget::hasFocus() [which follows to the focus proxy] on both widgets is false, so QWidget::clearFocus() doesn't call QApplicationPrivate::setFocusWidget(0) for either of them. At the time of the initial QApplicationPrivate::setFocusWidget (which happens when konqueror calls part->widget()->setFocus()), the WebEngineView doesn't have a focus proxy yet. That happens later, in QWebEngineViewPrivate::widgetChanged. QWidget::setFocusProxy doesn't update the app focus_proxy, that seems to be what's missing. No idea how it ever worked before though. Reproduced with unittest for Qt. Made a Qt fix. https://codereview.qt-project.org/c/qt/qtbase/+/268743 The Qt fix has been merged in (5.13 git branch, for now). I tried applying the patch from https://codereview.qt-project.org/c/qt/qtbase/+/268743 to the fedora source rpm for qt5-qtbase-5.12.5 (32bit) (and confirmed that it was correctly applied), but I still have the issue. Not sure if I did something wrong. I test by opening konqueror, splitting the view and closing one of the views. Immediate crash. I modified the patch to add qWarning() statements in the block of code being modified, and these get printed at runtime, showing the patch has applied and I am in fact running the patched Qt5. |