I tried out the KDevelop AppImage from here http://files.svenbrauch.de/kdevelop-linux/, specifically the build from 2016-06-21. The about dialog says this is v. 4.90.92, using KDE Frameworks 5.24.0 and Qt 5.6.1. On this build, I can consistently crash the entire application (not just the Kate part--I hope I'm correct thinking KDevelop uses that?) very easily in vi mode. All I have to do is set my keyboard layout to us (my physical keyboard is Swedish, I use us for development), hit '/' to enter search mode and type '_'. Instant crash. This does not happen if I use my native keyboard layout. Nor does it happen in ctrl+f search in normal mode, regardless of layout. Running from command-line, the only related output I get is /tmp/.mount_3SmjWq/AppRun: line 28: 11529 Segmentation fault (core dumped) kdevelop $@ Running in gdb, the only additional output is [Inferior 1 (process 11512) exited with code 0213] Telling gdb to print a backtrace just says "No stack." Reproducible: Always Steps to Reproduce: 1. Set keyboard layout to 'us' (native layout is 'se') 2. Activate vi mode 3. Type '/' to enter forward search 4. Type '_' Actual Results: Application crashes Expected Results: Cursor jumps to and highlights the next occurrence of the '_' character in the open buffer
For me, it does not crash, but it does not do anything either. I built KDevelop from source, version is 4.90.92 Arch Linux 64-bit KDE Frameworks 5.23.0 Qt 5.7 xcb wm
Also happens in current kate, I'm moving the bug. Just switch to vi input mode, press / _ -> crash. I can't generate a backtrace for some reason, but the top entry is 0x00007ffff2defb00 in QPlatformThemePrivate::currentKeyPlatforms() () from /usr/lib/libQt5Gui.so.5
No fancy keyboard layouts necessary here btw, this is a german keyboard with the standard de-latin1-nodeadkeys layout.
(In reply to Sven Brauch from comment #2) > Also happens in current kate, I'm moving the bug. Just switch to vi input > mode, press / _ -> crash. No crash for me. Arch Linux 64-bit Kate 16.04.2 KDE Frameworks 5.23.0 Qt 5.7 xcb wm
(In reply to Buovjaga from comment #4) > (In reply to Sven Brauch from comment #2) > > Also happens in current kate, I'm moving the bug. Just switch to vi input > > mode, press / _ -> crash. > > No crash for me. > > Arch Linux 64-bit > Kate 16.04.2 > KDE Frameworks 5.23.0 > Qt 5.7 > xcb wm Have you tried with 16.04.3-1 ? In my case, it crashes all the time if I press "shift" to change the character to be inserted with each key press. So, If I try to search with a keyword containing the '_' character, I would try to press 'shift' + '-' keys, and the crash would occur when pressing 'shift'. At first, it seems that the problem occurs with the '_' character, but this is only because the combination "shift" + '-' can be typed fast enough to think so. However, it just needs to press "shift" to crash it. E.g., trying to insert a capital letter (with shift), also crashes the editor. Copy and pasting strings that contain '_' with mouse works ok, so it's the shift key press event that triggers the problem.
Well, it' not only the "shift" key press that causes the problem. Most "control" keys are crashing the editor (CTRL, CAPS LOCK, ALT, etc.). Note that I am talking about a crash that occurs only when having set the editor in vi input mode, and pressing the mentioned keys in the search box (opened with '/' shortcut).
Assuming I'm looking at the same bug... For me it happens frequently when using '/', with a variety of keys and my usual UK keyboard layout. Reverting https://quickgit.kde.org/?p=ktexteditor.git&a=commit&h=025edb11ca9b0fa3685802e6c9cb608a4daa7911 avoids it. I get a loopy backtrace several tens of thousands of calls deep until the stack fills up - line 310 of emulatedcommandbar.cpp re-emits a key event, which is then handled again resulting in an endless cycle of duplicate events. The surrounding 'm_suspendEditEventFiltering' assignments seem intended to avoid these, but the only method checking that attribute is EmulatedCommandBar::eventFilter() which isn't called. KateViewInternal::eventFilter() *is* called, so the patch author might have been confused about which class object would handle the duplicated event.
Backtrace: #0 0x00007fffdb2d20b8 in ?? () from /usr/lib/qt/plugins/styles/breeze.so #1 0x00007ffff490d8b6 in QCoreApplicationPrivate::sendThroughApplicationEventFilters(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5 #2 0x00007ffff55ede78 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 #3 0x00007ffff55f6f86 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 #4 0x00007ffff7918857 in KateVi::EmulatedCommandBar::handleKeyPress (this=0xfa8c40, keyEvent=0x7fffff7ff6e0) at /home/flh/projects/ktexteditor/src/vimode/emulatedcommandbar/emulatedcommandbar.cpp:310 #5 0x00007ffff7902574 in KateVi::InputModeManager::handleKeypress (this=0x9e5160, e=0x7fffff7ff6e0) at /home/flh/projects/ktexteditor/src/vimode/inputmodemanager.cpp:147 #6 0x00007ffff78c199d in KateViInputMode::keyPress (this=0x93d460, e=0x7fffff7ff6e0) at /home/flh/projects/ktexteditor/src/inputmode/kateviinputmode.cpp:292 #7 0x00007ffff78c125f in KateViInputMode::stealKey (this=0x93d460, k=0x7fffff7ff6e0) at /home/flh/projects/ktexteditor/src/inputmode/kateviinputmode.cpp:144 #8 0x00007ffff782aa6b in KateViewInternal::eventFilter (this=0x9fdf80, obj=0x9ee140, e=0x7fffff7ff6e0) at /home/flh/projects/ktexteditor/src/view/kateviewinternal.cpp:2280 #9 0x00007ffff490d9e1 in QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5 #10 0x00007ffff55ede15 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 #11 0x00007ffff55f6f86 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 #12 0x00007ffff7918857 in KateVi::EmulatedCommandBar::handleKeyPress (this=0xfa8c40, keyEvent=0x7fffff7ffb00) at /home/flh/projects/ktexteditor/src/vimode/emulatedcommandbar/emulatedcommandbar.cpp:310 #13 0x00007ffff7902574 in KateVi::InputModeManager::handleKeypress (this=0x9e5160, e=0x7fffff7ffb00) at /home/flh/projects/ktexteditor/src/vimode/inputmodemanager.cpp:147 #14 0x00007ffff78c199d in KateViInputMode::keyPress (this=0x93d460, e=0x7fffff7ffb00) at /home/flh/projects/ktexteditor/src/inputmode/kateviinputmode.cpp:292 #15 0x00007ffff78c125f in KateViInputMode::stealKey (this=0x93d460, k=0x7fffff7ffb00) at /home/flh/projects/ktexteditor/src/inputmode/kateviinputmode.cpp:144 #16 0x00007ffff782aa6b in KateViewInternal::eventFilter (this=0x9fdf80, obj=0x9ee140, e=0x7fffff7ffb00) at /home/flh/projects/ktexteditor/src/view/kateviewinternal.cpp:2280 #17 0x00007ffff490d9e1 in QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5 #18 0x00007ffff55ede15 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 #19 0x00007ffff55f6f86 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 #20 0x00007ffff7918857 in KateVi::EmulatedCommandBar::handleKeyPress (this=0xfa8c40, keyEvent=0x7fffff7fff20) at /home/flh/projects/ktexteditor/src/vimode/emulatedcommandbar/emulatedcommandbar.cpp:310 #21 0x00007ffff7902574 in KateVi::InputModeManager::handleKeypress (this=0x9e5160, e=0x7fffff7fff20) at /home/flh/projects/ktexteditor/src/vimode/inputmodemanager.cpp:147 #22 0x00007ffff78c199d in KateViInputMode::keyPress (this=0x93d460, e=0x7fffff7fff20) at /home/flh/projects/ktexteditor/src/inputmode/kateviinputmode.cpp:292 #23 0x00007ffff78c125f in KateViInputMode::stealKey (this=0x93d460, k=0x7fffff7fff20) at /home/flh/projects/ktexteditor/src/inputmode/kateviinputmode.cpp:144 #24 0x00007ffff782aa6b in KateViewInternal::eventFilter (this=0x9fdf80, obj=0x9ee140, e=0x7fffff7fff20) at /home/flh/projects/ktexteditor/src/view/kateviewinternal.cpp:2280 #25 0x00007ffff490d9e1 in QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5 #26 0x00007ffff55ede15 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 #27 0x00007ffff55f6f86 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 #28 0x00007ffff7918857 in KateVi::EmulatedCommandBar::handleKeyPress (this=0xfa8c40, keyEvent=0x7fffff800340) at /home/flh/projects/ktexteditor/src/vimode/emulatedcommandbar/emulatedcommandbar.cpp:310 #29 0x00007ffff7902574 in KateVi::InputModeManager::handleKeypress (this=0x9e5160, e=0x7fffff800340) at /home/flh/projects/ktexteditor/src/vimode/inputmodemanager.cpp:147 #30 0x00007ffff78c199d in KateViInputMode::keyPress (this=0x93d460, e=0x7fffff800340) at /home/flh/projects/ktexteditor/src/inputmode/kateviinputmode.cpp:292 #31 0x00007ffff78c125f in KateViInputMode::stealKey (this=0x93d460, k=0x7fffff800340) at /home/flh/projects/ktexteditor/src/inputmode/kateviinputmode.cpp:144 #32 0x00007ffff782aa6b in KateViewInternal::eventFilter (this=0x9fdf80, obj=0x9ee140, e=0x7fffff800340) at /home/flh/projects/ktexteditor/src/view/kateviewinternal.cpp:2280 #33 0x00007ffff490d9e1 in QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5 #34 0x00007ffff55ede15 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 #35 0x00007ffff55f6f86 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 [...ad infinitum]
I was wrong above. EmulatedCommandBar::eventFilter() _is_ called, catches m_suspendEditEventFiltering and returns false to reject the event. Because the event was rejected it's propagated to KateViewInternal::eventFIlter(), which then causes the infinite loop. Despite the comment in EmulatedCommandBar::handleKeyPress() I'm still confused as to what the event duplication tries to achieve or why it's sent to a child widget. If the LineEdit accepts it we wouldn't have received the original, so it's guaranteed to loop?
Oh, and it doesn't have to be search, the usual colon-triggered command bar (and any others) are also affected.
I also can confirm this, master, kate and kdevelop on Plasma. The problematic line is emulatedcommandbar.cpp:310 where qApp->notify is called. It recurses into ... which calls handleKeyPress member function again, ... and so on. When the call to notify is removed, and function returns false in the if body, this works as it should. (just followed the "Ideally, instead of doing this, we would..." part of the comment written above the if) Another dirty fix that works is to check the value of m_suspendEditEventFiltering before setting it to true. I don't know the internals of KateVi to know whether this is the ok thing to do, it will allow recursion level 1 and cut anything deeper. if (m_edit->isVisible()) { + if (m_suspendEditEventFiltering) return false; m_suspendEditEventFiltering = true; QKeyEvent keyEventCopy(keyEvent->type(), keyEvent->key(), keyEvent->modifiers(), keyEvent->text(), keyEvent->isAutoRepeat(), keyEvent->count()); qApp->notify(m_edit, &keyEventCopy);
Just submit it IMO, this (grave) issue has been open far too long without anyone taking care of it. Just ccmail kwrite-devel, if somebody feels this is too dirty, they can step up. Thank you for investigating!
Review: https://phabricator.kde.org/D2597 Fixed in: http://commits.kde.org/ktexteditor/51dddd021ef05e4254924bb7e71f2317543f1a42
*** Bug 368129 has been marked as a duplicate of this bug. ***