Bug 381793 - Reproducible crash of Kate and Konqueror in KActionConflictDetector::eventFilter
Summary: Reproducible crash of Kate and Konqueror in KActionConflictDetector::eventFilter
Status: RESOLVED UPSTREAM
Alias: None
Product: frameworks-kxmlgui
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR crash
Target Milestone: ---
Assignee: David Faure
URL:
Keywords: drkonqi
: 384563 387789 388987 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-06-29 10:01 UTC by Sandeep Kumar
Modified: 2020-03-28 07:41 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sandeep Kumar 2017-06-29 10:01:32 UTC
Application: kate (16.08.2)
 (Compiled from sources)
Qt Version: 5.6.1
Frameworks Version: 5.26.0
Operating System: Linux 4.4.49-16-default x86_64
Distribution: "openSUSE Leap 42.2"

-- Information about the crash:
- What I was doing when the application crashed: The system was idle. And I was working on internet. When I started using Kate, it suddenly hanged up. This happen several times, sometimes Kate doesnt work for days.

- Unusual behavior I noticed: Sometimes, while working on a code, Kate suddenly hangs up and I have to restart my system. No other application also works.

The crash can be reproduced every time.

-- Backtrace:
Application: Kate (kate), signal: Segmentation fault
Using host libthread_db library "/lib64/libthread_db.so.1".
To enable execution of this file add
	add-auto-load-safe-path /global/linux/usrlibs/gcc/4.8.1/lib64/libstdc++.so.6.0.18-gdb.py
line to your configuration file "/home/kumar/.gdbinit".
To completely disable this security protection add
	set auto-load safe-path /
line to your configuration file "/home/kumar/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
	info "(gdb)Auto-loading safe path"
[Current thread is 1 (Thread 0x2b3511327dc0 (LWP 16776))]

Thread 2 (Thread 0x2b35304a5700 (LWP 16778)):
#0  0x00002b3516a5949d in poll () at /lib64/libc.so.6
#1  0x00002b351a4c5314 in  () at /usr/lib64/libglib-2.0.so.0
#2  0x00002b351a4c542c in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0
#3  0x00002b3515f7532b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5
#4  0x00002b3515f22fdb in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5
#5  0x00002b3515d5df1a in QThread::exec() () at /usr/lib64/libQt5Core.so.5
#6  0x00002b3515a491d5 in  () at /usr/lib64/libQt5DBus.so.5
#7  0x00002b3515d629e9 in  () at /usr/lib64/libQt5Core.so.5
#8  0x00002b351a013734 in start_thread () at /lib64/libpthread.so.0
#9  0x00002b3516a61d3d in clone () at /lib64/libc.so.6

Thread 1 (Thread 0x2b3511327dc0 (LWP 16776)):
[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*) () at /usr/lib64/libQt5Core.so.5
#10 0x00002b35146fde78 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5
#11 0x00002b351470249a in QApplication::notify(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5
#12 0x00002b3515f24fc5 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib64/libQt5Core.so.5
#13 0x00002b35147005cc in QApplication::setActiveWindow(QWidget*) () at /usr/lib64/libQt5Widgets.so.5
#14 0x00002b35147007d3 in QApplicationPrivate::notifyActiveWindowChange(QWindow*) () at /usr/lib64/libQt5Widgets.so.5
#15 0x00002b3514f13b95 in QGuiApplicationPrivate::processActivatedEvent(QWindowSystemInterfacePrivate::ActivatedWindowEvent*) () at /usr/lib64/libQt5Gui.so.5
#16 0x00002b3514f13eed in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) () at /usr/lib64/libQt5Gui.so.5
#17 0x00002b3514ef5eeb in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Gui.so.5
#18 0x00002b352464abc0 in  () at /usr/lib64/libQt5XcbQpa.so.5
#19 0x00002b351a4c5134 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0
#20 0x00002b351a4c5388 in  () at /usr/lib64/libglib-2.0.so.0
#21 0x00002b351a4c542c in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0
#22 0x00002b3515f7530c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5
#23 0x00002b3515f22fdb in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5
#24 0x00002b3515f2aec6 in QCoreApplication::exec() () at /usr/lib64/libQt5Core.so.5
#25 0x000000000044896b in main ()

Reported using DrKonqi
Comment 1 Christoph Cullmann 2017-12-20 20:19:33 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*) ()
Comment 2 Christoph Cullmann 2017-12-20 20:20:23 UTC
*** Bug 384563 has been marked as a duplicate of this bug. ***
Comment 3 Christoph Cullmann 2017-12-20 20:21:11 UTC
*** Bug 387789 has been marked as a duplicate of this bug. ***
Comment 4 Christoph Cullmann 2017-12-20 20:23:11 UTC
Like in bug 384563, we seem to crash in KActionConflictDetector, perhaps like in the other bug in:

kactionconflictdetector.cpp:44
Comment 5 Aleix Pol 2018-01-15 14:21:28 UTC
*** Bug 381814 has been marked as a duplicate of this bug. ***
Comment 6 Aleix Pol 2018-01-15 14:21:51 UTC
*** Bug 388987 has been marked as a duplicate of this bug. ***
Comment 7 Roman Fietze 2018-02-04 09:46:06 UTC
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.
Comment 8 Raphael Rosch 2019-07-25 07:29:10 UTC
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.
Comment 9 Raphael Rosch 2019-07-25 07:56:51 UTC
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?
Comment 10 David Faure 2019-07-27 11:12:50 UTC
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.
Comment 11 David Faure 2019-07-27 12:21:20 UTC
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.
Comment 12 David Faure 2019-07-27 19:20:43 UTC
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
Comment 13 David Faure 2019-07-30 08:16:29 UTC
The Qt fix has been merged in (5.13 git branch, for now).
Comment 14 Raphael Rosch 2020-03-28 07:41:10 UTC
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.