Created attachment 135645 [details] Log of crash in Manjaro SUMMARY I get the attached stacktrace as soon as I close the Preferences dialog on a master build. STEPS TO REPRODUCE 1. Edit anything on the Preferences dialog. 2. Close it. OBSERVED RESULT Crash after a theme changed signal is fired. EXPECTED RESULT Krita keeps on working. SOFTWARE/OS VERSIONS Windows: -- macOS: -- Linux/KDE Plasma: Manjaro 20.2.1 (available in About System) KDE Plasma Version: -- KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION The crash also happens on Windows with dependencies built from 3rdparty.
I don't get a crash with the latest master on windows with home-built deps.
I also don't get a crash on Linux with Qt 5.15.2, though there is a long delay after closing the preferences dialog and I see a canvas popup message about zoom several times.
It might be worth it to install Qt's debug symbols, since the crash happens inside Qt. Maybe it's got something to do with the platform plugin or the widget style? I'm using fusion on plasma.
*** Bug 432950 has been marked as a duplicate of this bug. ***
Manjaro doesn't carry debug symbols :/
I'm getting the crash too, same backtrace, compiled with Ubuntu 20.04 libs (Qt 5.12.8). Unfortunately Ubuntu doesn't seem to have a package with Qt debug symbols either... As the bug marked as duplicate mentions, you need to have closed a document before accepting new settings to reproduce. Fusion or Breeze style doesn't seem to matter, crashes either way.
The commit that introduced the crash seems to be this one: https://invent.kde.org/graphics/krita/-/commit/df2fecf30cec9de04eb50e4dc5e5521850ff8f7f It is also the cause why toggling the options like "Temporarily Save Tweaks to Presets" at the bottom of the brush settings editor is super laggy now (unless it also just triggers this crash, that is) And I'm not 100% sure if it's related, but the brush editor in general behaves a bit weird here, like randomly resizing fonts or the whole popup size as I edit settings. The crash itself might be a Qt bug, I've noticed on other occasions that Qt is touchy if you access any style/palette related things right after changing palette until it is done handling the PaletteChanged QEvents.
I only get the crash when I have no image open. ================================= Thread 1 (Thread 0x7fffeed10d00 (LWP 3406001)): #0 0x00007ffff511c8d2 in () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #1 0x00007ffff511cc70 in () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #2 0x00007ffff70768aa in KisMainWindow::slotThemeChanged() (this=0x555557588a20) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qcoreapplication.h:116 #3 0x00007ffff7087585 in KisMainWindow::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (_o=0x555557588a20, _c=<optimized out>, _id=<optimized out>, _a=<optimized out>) at /home/wolthera/krita/build/libs/ui/kritaui_autogen/include/moc_KisMainWindow.cpp:424 #4 0x00007ffff45cd6f0 in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x00007ffff70b6f3a in Digikam::ThemeManager::slotChangePalette() (this=0x55555fad6640) at /home/wolthera/krita/src/libs/ui/thememanager.cpp:193 #6 0x00007ffff70b7330 in Digikam::ThemeManager::setCurrentTheme(QString const&) (this=this@entry=0x55555fad6640, name=...) at /home/wolthera/krita/src/libs/ui/thememanager.cpp:131 #7 0x00007ffff707b126 in KisMainWindow::configChanged() (this=0x555557588a20) at /home/wolthera/krita/src/libs/ui/KisMainWindow.cpp:2589 #8 0x00007ffff7087542 in KisMainWindow::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (_o=0x555557588a20, _c=<optimized out>, _id=<optimized out>, _a=<optimized out>) at /home/wolthera/krita/build/libs/ui/kritaui_autogen/include/moc_KisMainWindow.cpp:430 #9 0x00007ffff45cd6f0 in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #10 0x00007ffff6cfe958 in KisConfig::setSwitchSelectionCtrlAlt(bool) (this=this@entry=0x7fffffffcb30, value=<optimized out>) at /home/wolthera/krita/src/libs/ui/kis_config.cc:2078 #11 0x00007ffff6c4d2dc in KisDlgPreferences::editPreferences() (this=this@entry=0x55556035c6b0) at /home/wolthera/krita/src/libs/ui/dialogs/kis_dlg_preferences.cc:1831 #12 0x00007ffff707ef4d in KisMainWindow::slotPreferences() (this=0x555557588a20) at /home/wolthera/krita/src/libs/ui/KisMainWindow.cpp:785 #13 0x00007ffff708775b in KisMainWindow::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (_o=0x555557588a20, _c=<optimized out>, _id=<optimized out>, _a=<optimized out>) at /home/wolthera/krita/build/libs/ui/kritaui_autogen/include/moc_KisMainWindow.cpp:377 #14 0x00007ffff45cd6f0 in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #15 0x00007ffff50678e6 in QAction::triggered(bool) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #16 0x00007ffff5069fb8 in QAction::activate(QAction::ActionEvent) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #17 0x00007ffff51f46a2 in () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #18 0x00007ffff51fbdee in () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #19 0x00007ffff51fd082 in QMenu::mouseReleaseEvent(QMouseEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #20 0x00007ffff50b0c06 in QWidget::event(QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #21 0x00007ffff51ff68b in QMenu::event(QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #22 0x00007ffff506ddc3 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #23 0x00007ffff5076e77 in QApplication::notify(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #24 0x00007ffff7038d7d in KisApplication::notify(QObject*, QEvent*) (this=<optimized out>, receiver=0x55556976f7e0, event=0x7fffffffd5c0) at /home/wolthera/krita/src/libs/ui/KisApplication.cpp:710 #25 0x00007ffff459669a in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #26 0x00007ffff50760a7 in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool, bool) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #27 0x00007ffff50cc8ee in () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #28 0x00007ffff50cf174 in () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #29 0x00007ffff506ddc3 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #30 0x00007ffff5076bb8 in QApplication::notify(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #31 0x00007ffff7038d7d in KisApplication::notify(QObject*, QEvent*) (this=<optimized out>, receiver=0x5555602d2410, event=0x7fffffffdac0) at /home/wolthera/krita/src/libs/ui/KisApplication.cpp:710
Oh, when I restarted, Krita apparantly thought I had an opengl crash as my opengl was disabled ._.
It doesn't only crash with no document open here, but apparently after closing any document. For example if you closed only one of multiple open documents it'll also crash when changing settings.
I don't get the crash myself, but does this patch solve the issue? diff --git a/libs/ui/KisMainWindow.cpp b/libs/ui/KisMainWindow.cpp index d23b3b0511..c0090dc1e9 100644 --- a/libs/ui/KisMainWindow.cpp +++ b/libs/ui/KisMainWindow.cpp @@ -422,9 +422,6 @@ KisMainWindow::KisMainWindow(QUuid uuid) connect(d->styleActions, SIGNAL(triggered(QAction*)), this, SLOT(slotUpdateWidgetStyle())); - - - Q_FOREACH (QDockWidget *wdg, dockWidgets()) { if ((wdg->features() & QDockWidget::DockWidgetClosable) == 0) { wdg->setVisible(true); @@ -2556,8 +2553,11 @@ void KisMainWindow::configChanged() #endif KConfigGroup group( KSharedConfig::openConfig(), "theme"); - d->themeManager->setCurrentTheme(group.readEntry("Theme", "Krita dark")); - d->actionManager()->updateGUI(); + QString theme (group.readEntry("Theme", "Krita dark")); + if (d->themeManager->currentThemeName() != theme) { + d->themeManager->setCurrentTheme(theme); + d->actionManager()->updateGUI(); + } QString s = cfg.getMDIBackgroundColor(); KoColor c = KoColor::fromXML(s);
Well, yes and no. It doesn't try to update the theme anymore on "normal" configuraton changes, and hence doesn't crash. That also makes the option switching in the brush editor pretty much instant. But actual theme changes from the settings menu are still crashing.
Hm, maybe we can use a delayed sig/slot connection for those.
Created attachment 137007 [details] Crash log (only one thread though) I got this crash while having a document open in appimage after checking "switch eraser size". The crashlog is a bit empty since it doesn't have debug symbols, but it does show clearly that it comes from that checkbox. I don't see why Krita would attempt to change theme just because some checkbox got activated?... The version I used was 1ea07f2. ---- Thread 1 "AppRun" received signal SIGSEGV, Segmentation fault. 0x00007ffff49a6e81 in ?? () from /tmp/.mount_krita-mLlIZy/usr/bin/../lib/libQt5Widgets.so.5 (gdb) bt #0 0x00007ffff49a6e81 in ?? () from /tmp/.mount_krita-mLlIZy/usr/bin/../lib/libQt5Widgets.so.5 #1 0x00007ffff49a71e8 in ?? () from /tmp/.mount_krita-mLlIZy/usr/bin/../lib/libQt5Widgets.so.5 #2 0x00007ffff6f17bef in KisMainWindow::slotThemeChanged() () from /tmp/.mount_krita-mLlIZy/usr/bin/../lib/libkritaui.so.17 #3 0x00007ffff6f27e3f in ?? () from /tmp/.mount_krita-mLlIZy/usr/bin/../lib/libkritaui.so.17 #4 0x00007ffff3e516f9 in QMetaObject::activate(QObject*, int, int, void**) () from /tmp/.mount_krita-mLlIZy/usr/bin/../lib/libQt5Core.so.5 #5 0x00007ffff6f4eea1 in ?? () from /tmp/.mount_krita-mLlIZy/usr/bin/../lib/libkritaui.so.17 #6 0x00007ffff6f4f251 in ?? () from /tmp/.mount_krita-mLlIZy/usr/bin/../lib/libkritaui.so.17 #7 0x00007ffff6f1c4d3 in KisMainWindow::configChanged() () from /tmp/.mount_krita-mLlIZy/usr/bin/../lib/libkritaui.so.17 #8 0x00007ffff6f27e82 in ?? () from /tmp/.mount_krita-mLlIZy/usr/bin/../lib/libkritaui.so.17 #9 0x00007ffff3e516f9 in QMetaObject::activate(QObject*, int, int, void**) () from /tmp/.mount_krita-mLlIZy/usr/bin/../lib/libQt5Core.so.5 #10 0x00007ffff6c2cea3 in KisConfig::setUseEraserBrushOpacity(bool) () from /tmp/.mount_krita-mLlIZy/usr/bin/../lib/libkritaui.so.17 #11 0x00007ffff6caecdc in KisPaintopBox::slotEraserBrushOpacityToggled(bool) () from /tmp/.mount_krita-mLlIZy/usr/bin/../lib/libkritaui.so.17 #12 0x00007ffff6b1dbbc in ?? () from /tmp/.mount_krita-mLlIZy/usr/bin/../lib/libkritaui.so.17 #13 0x00007ffff3e516f9 in QMetaObject::activate(QObject*, int, int, void**) () from /tmp/.mount_krita-mLlIZy/usr/bin/../lib/libQt5Core.so.5
I fixed that bug in commit 44d8ed8945fcc704ba429a001f36caaa4766f8cf Author: Halla Rempt <halla@valdyas.org> Date: Thu Mar 18 14:49:03 2021 +0100 Don't set the theme if it hasn't changed Changing the theme taks about two seconds on my system, so let's not do Which also fixed the problem that changing ticking those checkboxes took 2 seconds because all the widgets got a new style applied. Really changing the theme would still crash for people with a version of Qt that shows the crash -- mine doesn't.
Does this diff fix anything? It makes the sig/slot queued diff --git a/libs/ui/KisMainWindow.cpp b/libs/ui/KisMainWindow.cpp index ef44ce4783..7522cf7ae7 100644 --- a/libs/ui/KisMainWindow.cpp +++ b/libs/ui/KisMainWindow.cpp @@ -2773,7 +2773,7 @@ void KisMainWindow::createActions() d->themeManager->setThemeMenuAction(new KActionMenu(i18nc("@action:inmenu", "&Themes"), this)); d->themeManager->registerThemeActions(actionCollection()); - connect(d->themeManager, SIGNAL(signalThemeChanged()), this, SLOT(slotThemeChanged()), Qt::UniqueConnection); + connect(d->themeManager, SIGNAL(signalThemeChanged()), this, SLOT(slotThemeChanged()), Qt::QueuedConnection); connect(d->themeManager, SIGNAL(signalThemeChanged()), d->welcomePage, SLOT(slotUpdateThemeColors()), Qt::UniqueConnection); d->toggleDockers = actionManager->createAction("view_toggledockers"); lines 1-13/13 (END)
I've not gotten a crash in windows during the past few days. Closing for now, will reopen if I get it again.
Created attachment 137253 [details] Screenshot of Krita with a wrong theme I am a bit worried though, because why would this signal even be sent? I got Krita changing the theme to bright on its own twice already. I don't get the crash anymore, but the theme shouldn't change on its own. Note that it also behaves inconsistently, there are some elements that are still dark. What is sending those signals and why? (I must say that I did change a system recently so it might be a different system than before, but I also see that there was a change recently). Btw I did have this issue before on Windows - but it was long time ago, back when I was still painting there (I remember the colors in the Layers docker on color labeled layers getting bright so text was unreadable). It's probably irrelevant now... but just for the sake of completeness, I did see it before. Workaround: just go to Settings -> Themes -> Krita dark, or Krita bright and then Krita dark, and it changes again.
* Which signal do you mean? * I don't think Krita can change the color theme on its own. * And yes, not all elements follow the theme change properly.