Bug 399696 - Forced close with Internal Error message in kis_shortcut_matcher.cpp, line 557 [USE_QT_XCB]
Summary: Forced close with Internal Error message in kis_shortcut_matcher.cpp, line 55...
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: General (show other bugs)
Version: unspecified
Platform: Appimage Linux
: NOR crash
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-12 08:47 UTC by Tyson Tan
Modified: 2019-03-26 15:30 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Internal Error message in kis_shortcut_matcher.cpp, line 557 (36.96 KB, image/png)
2018-10-12 08:47 UTC, Tyson Tan
Details
kis_shortcut_matcher.cpp line 557 internal error (221.92 KB, image/png)
2019-03-17 13:39 UTC, Tyson Tan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tyson Tan 2018-10-12 08:47:35 UTC
Created attachment 115592 [details]
Internal Error message in kis_shortcut_matcher.cpp, line 557

SUMMARY
Krita force closed with an Internal Error message about something wrong in kis_shortcut_matcher.cpp, line 557

Tested with:
krita-4.2.0-pre-alpha-539f7d0-x86_64.appimage
Manjaro GNOME 17.1.12 (Gnome 3.30)

I was making another non-Krita applet "Always on Top" when it happened. A mouse cursor kept being displayed besides the brush ring. This usually happens before when I clicked outside of Krita once and can be fixed by clicking on Krita's title bar or change tools. Not this time. After struggling with it for a while, the Internal Error message popped up and Krita force itself to close.

STEPS TO REPRODUCE
1. 
2. 
3. 

OBSERVED RESULT


EXPECTED RESULT


SOFTWARE VERSIONS
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 Halla Rempt 2018-10-12 08:53:43 UTC
That sounds like it would be hard to reproduce without that applet -- apparently it keeps sending key events to Krita?
Comment 2 Halla Rempt 2018-10-12 08:57:07 UTC
Btw, it should be safe enough to press ignore so Krita doesn't close.
Comment 3 Halla Rempt 2018-10-12 12:10:18 UTC
It is related to the experimental option to use Qt's xcb implementation, instead of our fork. Our fork breaks scrollwheel input with current versions of X11; Qt's seems to send events in a weird order and can break switching focus and when moving from the dockers to the canvas. 

This is the full backtrace:

Thread 1 (Thread 0x7fda2898b980 (LWP 25331)):
[KCrash Handler]
#6  0x00007fda1c625f67 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
#7  0x00007fda1c62733a in __GI_abort () at abort.c:78
#8  0x00007fda1d2c0f1c in QMessageLogger::fatal(char const*, ...) const () from /usr/lib64/libQt5Core.so.5
#9  0x00007fda23c5e360 in kis_assert_common (assertion=assertion@entry=0x7fda283757a9 "!m_d->readyShortcut", file=file@entry=0x7fda28375840 "/home/boud/dev/krita/libs/ui/input/kis_shortcut_matcher.cpp", line=line@entry=557, throwException=throwException@entry=false, isIgnorable=isIgnorable@entry=true) at /home/boud/dev/krita/libs/global/kis_assert.cpp:90
#10 0x00007fda23c5e66d in kis_safe_assert_recoverable (assertion=assertion@entry=0x7fda283757a9 "!m_d->readyShortcut", file=file@entry=0x7fda28375840 "/home/boud/dev/krita/libs/ui/input/kis_shortcut_matcher.cpp", line=line@entry=557) at /home/boud/dev/krita/libs/global/kis_assert.cpp:108
#11 0x00007fda27e1af1b in KisShortcutMatcher::forceEndRunningShortcut (this=<optimized out>, localPos=...) at /home/boud/dev/krita/libs/ui/input/kis_shortcut_matcher.cpp:557
#12 0x00007fda27e1afef in KisShortcutMatcher::lostFocusEvent (this=<optimized out>, localPos=...) at /home/boud/dev/krita/libs/ui/input/kis_shortcut_matcher.cpp:377
#13 0x00007fda27dfafc0 in KisInputManager::eventFilterImpl (this=0xa9a9e30, event=0x7ffc0e440e80) at /home/boud/dev/krita/libs/ui/input/kis_input_manager.cpp:443
#14 0x00007fda1d49476e in QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) () from /usr/lib64/libQt5Core.so.5
#15 0x00007fda1e43f185 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5
#16 0x00007fda1e445b52 in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5
#17 0x00007fda27e7a8d7 in KisApplication::notify (this=<optimized out>, receiver=0xe119930, event=0x7ffc0e440e80) at /home/boud/dev/krita/libs/ui/KisApplication.cpp:608
#18 0x00007fda1d4948f5 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib64/libQt5Core.so.5
#19 0x00007fda1e443911 in QApplicationPrivate::setFocusWidget(QWidget*, Qt::FocusReason) () from /usr/lib64/libQt5Widgets.so.5
#20 0x00007fda1e474c7b in QWidget::setFocus(Qt::FocusReason) () from /usr/lib64/libQt5Widgets.so.5
#21 0x00007fda1e441199 in QApplicationPrivate::giveFocusAccordingToFocusPolicy(QWidget*, QEvent*, QPoint) () from /usr/lib64/libQt5Widgets.so.5
#22 0x00007fda1e44764b in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5
#23 0x00007fda27e7a8d7 in KisApplication::notify (this=<optimized out>, receiver=0xcb72c50, event=0x7ffc0e441360) at /home/boud/dev/krita/libs/ui/KisApplication.cpp:608
#24 0x00007fda1d4948f5 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib64/libQt5Core.so.5
#25 0x00007fda1e4451e9 in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) () from /usr/lib64/libQt5Widgets.so.5
#26 0x00007fda1e49349f in ?? () from /usr/lib64/libQt5Widgets.so.5
#27 0x00007fda1e495993 in ?? () from /usr/lib64/libQt5Widgets.so.5
#28 0x00007fda1e43f1ac in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5
#29 0x00007fda1e445b52 in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5
#30 0x00007fda27e7a8d7 in KisApplication::notify (this=<optimized out>, receiver=0xa420850, event=0x7ffc0e441800) at /home/boud/dev/krita/libs/ui/KisApplication.cpp:608
#31 0x00007fda1d4948f5 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib64/libQt5Core.so.5
#32 0x00007fda1da2d74f in QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) () from /usr/lib64/libQt5Gui.so.5
#33 0x00007fda1da2f855 in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) () from /usr/lib64/libQt5Gui.so.5
#34 0x00007fda1da0e7eb in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Gui.so.5
#35 0x00007fda11c7308b in ?? () from /usr/lib64/libQt5XcbQpa.so.5
#36 0x00007fda1d49308b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#37 0x00007fda1d49b770 in QCoreApplication::exec() () from /usr/lib64/libQt5Core.so.5
#38 0x000000000040642f in main (argc=<optimized out>, argv=0x7ffc0e441d28) at /home/boud/dev/krita/krita/main.cc:456
Comment 4 Tyson Tan 2018-10-12 12:13:15 UTC
# About the applet:

The applet is xsensors. Its only function is to show the hardware's temperature. It has nothing to do with Krita what so ever. It has 4 tabs inside its interface. That it. It doesn't even have a menu.


# Pressing Ignore:

I did press Ignore, but new INTERNAL ERROR messagebox just kept popping up. It was in an constant INTERNAL ERROR loop. Only Abort stopped the madness.


# P.S. Krita's OpenGL stress

I'm using xsensors to investigate my Wacom MSP13 (and other laptops) keeps hard resetting themselves under Linux. I think it is an Intel integrated graphics specific problem because there is no GPU thermal sensor being provided under Linux. The GPU part turbo boosts under stress, overheats itself until it shuts down by hardware safety measures. 

A peculiar finding: Krita is very good at making the GPU overheating, too good. 

I was trying this seemingly demanding WebGL2 demo: https://playcanv.as/e/p/44MRmJRU/ which on MSP13 it couldn't even run past 10 FPS under Ultra setting. However, the CPU package temperature rarely went over 60C. 

On the other hand, a few simple dabs in Krita and it immediately shoots all the way over 70C. If I combine drawing with rotation, panning, zooming, picking color...all these OpenGL actions, MSP13 just kills itself very soon after.

Keep in mind this is not only happening on MSP13, but also a number of different laptops I tried Krita on them.

Any insight about what is happening here? Anything more I can do to investigate to help, or I should report this as another bug?
Comment 5 Halla Rempt 2018-10-12 12:16:22 UTC
No, I don't have any idea about that -- I don't see such problems on my mobile studio pro 15", but in any case, it's not about this issue.
Comment 6 Tyson Tan 2018-10-15 01:09:43 UTC
(In reply to Boudewijn Rempt from comment #5)
> No, I don't have any idea about that -- I don't see such problems on my
> mobile studio pro 15", but in any case, it's not about this issue.

Off-topic here sorry. But: MSP 16 has an nvidia GPU, so when the GPU is stressed, it will automatically switch to the NV GPU, therefore avoiding intel GPU's overheating problem under Linux. I have been testing a few workarounds and they seems to work by suppressing CPU package's power cap. I will do some more research and report the the issue to where it should be.
Comment 7 Dmitry Kazakov 2019-03-11 15:39:06 UTC
The bug should be fixed in 

https://phabricator.kde.org/R37:a3193fe273c3f2c3b5493f77724a4bc099ae5e36
Comment 8 Tyson Tan 2019-03-11 16:30:29 UTC
(In reply to Dmitry Kazakov from comment #7)
> The bug should be fixed in 
> 
> https://phabricator.kde.org/R37:a3193fe273c3f2c3b5493f77724a4bc099ae5e36

Thank you Dmitry! :)
Comment 9 Tyson Tan 2019-03-17 13:39:20 UTC
Created attachment 118858 [details]
kis_shortcut_matcher.cpp line 557 internal error

The same type of crash is happening since nightly build 5c108ea. Appears to be totally random when pressing down any key.
Comment 10 wolthera 2019-03-17 17:53:00 UTC
Err, tyson, did you want to reopen this?
Comment 11 Tyson Tan 2019-03-18 00:50:09 UTC
(In reply to wolthera from comment #10)
> Err, tyson, did you want to reopen this?

Yeah? But I was not sure about whether it has already been solved or not judging by the recent change log of the nightly build. So I thought leaving a message first.

I will just reopen this. It gets so bad Krita is pretty much too unstable to use like that.
Comment 12 Tyson Tan 2019-03-18 01:00:19 UTC
Information about the recent internal errors.

This time around I was using Krita totally in a normal way. The internal error seems to be occurring at a random fashion. Sometimes within the first few actions following the opening of a document.

When the internal error is about to happen (but the error popup has not appeared yet), no operation will be reflected on the canvas, the cursor is locked in place. 

The popup looks like this: https://bugs.kde.org/attachment.cgi?id=118858 But pressing Ignore won't turn Krita usable again. Press Abort will close Krita. Fortunately the popup is not popping up non-stop, and Krita still listens to Ctrl+S so I was able to save my progress. However there was one occasion Krita just crashed after showing signs of internal error but without showing any message.
Comment 13 Dmitry Kazakov 2019-03-21 14:28:43 UTC
Hi, Tyson!

Could you check the very latest AppImage? It looks like older builds had non-patched Qt in it, so the problem was not fixed completely. The latest AppImage seem to have this problem solved:

https://binary-factory.kde.org/job/Krita_Nightly_Appimage_Build/


PS:
I should still try to fix this problem for the distribution builds, but it is a separate task.
Comment 14 Tyson Tan 2019-03-22 11:46:47 UTC
(In reply to Dmitry Kazakov from comment #13)
> Hi, Tyson!
> 
> Could you check the very latest AppImage? It looks like older builds had
> non-patched Qt in it, so the problem was not fixed completely. The latest
> AppImage seem to have this problem solved:
> 
> https://binary-factory.kde.org/job/Krita_Nightly_Appimage_Build/
> 
> 
> PS:
> I should still try to fix this problem for the distribution builds, but it
> is a separate task.

Thanks Dmitry, it's not crashing anymore. Another one of those elusive upstream complications, huh? I hope it doesn't make your days too difficult! :)
Comment 15 Dmitry Kazakov 2019-03-25 18:21:56 UTC
Git commit 44080b7b7af892e410bf3bb5b2f19ea785f760fb by Dmitry Kazakov.
Committed on 25/03/2019 at 18:21.
Pushed by dkazakov into branch 'master'.

Add a workaround for Qt 5.9...5.11.X to fix tablet support

Basically, the patch mimics this Qt's patch that has been
added in Qt 5.12.0 only:
https://codereview.qt-project.org/#/c/239918/

M  +22   -0    libs/ui/input/kis_input_manager_p.cpp

https://commits.kde.org/krita/44080b7b7af892e410bf3bb5b2f19ea785f760fb
Comment 16 Halla Rempt 2019-03-26 15:30:39 UTC
Git commit 0218025b1725aa810f108d08802b590ce62f1044 by Boudewijn Rempt, on behalf of Dmitry Kazakov.
Committed on 26/03/2019 at 15:29.
Pushed by rempt into branch 'krita/4.1'.

Add a workaround for Qt 5.9...5.11.X to fix tablet support

Basically, the patch mimics this Qt's patch that has been
added in Qt 5.12.0 only:
https://codereview.qt-project.org/#/c/239918/

M  +22   -0    libs/ui/input/kis_input_manager_p.cpp

https://commits.kde.org/krita/0218025b1725aa810f108d08802b590ce62f1044