Summary: | digikam 7.2.0-rc crashes on startup (beta2 didn't) | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Norbert Preining <norbert> |
Component: | Usability-Themes | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | caulier.gilles, metzpinguin |
Priority: | NOR | ||
Version: | 7.2.0 | ||
Target Milestone: | --- | ||
Platform: | Debian unstable | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 7.2.0 | |
Sentry Crash Report: |
Description
Norbert Preining
2021-02-08 14:51:32 UTC
Sorry, now I added debug symbols for the breeze stuff, I get the following backtrace:: Thread 1 "digikam" received signal SIGSEGV, Segmentation fault. QExplicitlySharedDataPointer<KSharedConfig>::~QExplicitlySharedDataPointer (this=0x7fffffffcde0, __in_chrg=<optimized out>) at /usr/include/c++/10/bits/atomic_base.h:333 333 operator--() noexcept (gdb) bt #0 QExplicitlySharedDataPointer<KSharedConfig>::~QExplicitlySharedDataPointer (this=0x7fffffffcde0, __in_chrg=<optimized out>) at /usr/include/c++/10/bits/atomic_base.h:333 #1 0x00007fffcc1fd421 in QExplicitlySharedDataPointer<KSharedConfig>::operator= (other=..., this=<optimized out>) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qshareddata.h:226 #2 Breeze::AppListener::eventFilter (this=0x555555e43e50, watched=<optimized out>, event=<optimized out>) at ./kstyle/breezetoolsareamanager.cpp:152 #3 0x00007ffff57e1b46 in QCoreApplicationPrivate::sendThroughApplicationEventFilters(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x00007ffff62a3198 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #5 0x00007ffff57e1f0a in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x00007ffff581715f in QObject::setProperty(char const*, QVariant const&) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x00007ffff70b0742 in Digikam::ThemeManager::slotChangePalette ( this=0x7ffff75af690 <Digikam::(anonymous namespace)::Q_QGS_creator::innerFunction()::holder>) at ./core/libs/widgets/mainview/thememanager.cpp:133 #8 0x00007ffff70b0ab0 in Digikam::ThemeManager::setCurrentTheme ( this=0x7ffff75af690 <Digikam::(anonymous namespace)::Q_QGS_creator::innerFunction()::holder>, name=...) at ./core/libs/widgets/mainview/thememanager.cpp:112 #9 0x00007ffff70b1302 in Digikam::ThemeManager::populateThemeMenu ( this=0x7ffff75af690 <Digikam::(anonymous namespace)::Q_QGS_creator::innerFunction()::holder>) at ./core/libs/widgets/mainview/thememanager.cpp:234 #10 0x00007ffff7a78ed0 in Digikam::DigikamApp::populateThemes (this=0x555556703640) at ./core/app/main/digikamapp_setup.cpp:1024 #11 0x00007ffff7a801da in Digikam::DigikamApp::setupActions (this=this@entry=0x555556703640) at ./core/app/main/digikamapp_setup.cpp:796 #12 0x00007ffff7a6cfad in Digikam::DigikamApp::DigikamApp (this=0x555556703640, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at ./core/app/main/digikamapp.cpp:151 #13 0x0000555555559e62 in main (argc=<optimized out>, argv=0x7fffffffd880) at ./core/app/main/main.cpp:355 It crash in KDE breeze colors/widgets theme, not digiKam.... Gilles Caulier I agree with that, but beta2 didn't crash ;-) If i'm not too wrong, you don't use AppImage bundle that we compile, but a native digiKam version packaged from Debian. Right ? Gilles Caulier Yes, the packages are compiled by me (like all of frameworks, plasma, etc). Maybe a Plasma 5.20.90 issue? Can you test with the 7.2.0-rc AppImage availble here to see if problem is reproducible ? https://files.kde.org/digikam/ Gilles Caulier >Maybe a Plasma 5.20.90 issue?
Perhaps, i don't know...
Gilles Caulier
kstyle/breezetoolsareamanager.cpp:152 This line no longer matches the current git/master version. Update the KF5 branch, some code has been reverted in the last 2 weeks. That is of course the problem when you swim with the git/master branch in such large projects. Maik I updated breeze from the state of today's git repo, branch "Plasma/521", but I still get failures in this code in breeze: if (ev->propertyName() == colorProperty) { if (qApp && qApp->property(colorProperty).isValid()) { auto path = qApp->property(colorProperty).toString(); manager->_config = KSharedConfig::openConfig(path); } else { --> manager->_config = KSharedConfig::openConfig(); } manager->_watcher = KConfigWatcher::create(manager->_config); The backtrace is now #0 QExplicitlySharedDataPointer<KSharedConfig>::~QExplicitlySharedDataPointer (this=0x7fffffffcdb0, __in_chrg=<optimized out>) at /usr/include/c++/10/bits/atomic_base.h:333 #1 0x00007fffcc1fd361 in QExplicitlySharedDataPointer<KSharedConfig>::operator= (other=..., this=<optimized out>) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qshareddata.h:226 #2 Breeze::AppListener::eventFilter (this=0x555555e43760, watched=<optimized out>, event=<optimized out>) at ./kstyle/breezetoolsareamanager.cpp:145 #3 0x00007ffff57e1b46 in QCoreApplicationPrivate::sendThroughApplicationEventFilters(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x00007ffff62a3198 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #5 0x00007ffff57e1f0a in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x00007ffff581715f in QObject::setProperty(char const*, QVariant const&) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x00007ffff70b0742 in Digikam::ThemeManager::slotChangePalette ( this=0x7ffff75af690 <Digikam::(anonymous namespace)::Q_QGS_creator::innerFunction()::holder>) at ./core/libs/widgets/mainview/thememanager.cpp:133 #8 0x00007ffff70b0ab0 in Digikam::ThemeManager::setCurrentTheme ( this=0x7ffff75af690 <Digikam::(anonymous namespace)::Q_QGS_creator::innerFunction()::holder>, name=...) at ./core/libs/widgets/mainview/thememanager.cpp:112 #9 0x00007ffff70b1302 in Digikam::ThemeManager::populateThemeMenu ( this=0x7ffff75af690 <Digikam::(anonymous namespace)::Q_QGS_creator::innerFunction()::holder>) at ./core/libs/widgets/mainview/thememanager.cpp:234 #10 0x00007ffff7a78ed0 in Digikam::DigikamApp::populateThemes (this=0x555556758200) at ./core/app/main/digikamapp_setup.cpp:1024 #11 0x00007ffff7a801da in Digikam::DigikamApp::setupActions (this=this@entry=0x555556758200) at ./core/app/main/digikamapp_setup.cpp:796 #12 0x00007ffff7a6cfad in Digikam::DigikamApp::DigikamApp (this=0x555556758200, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at ./core/app/main/digikamapp.cpp:151 #13 0x0000555555559e62 in main (argc=<optimized out>, argv=0x7fffffffd850) at ./core/app/main/main.cpp:355 I don't see anything else that needs updating here, all the other packages involved, in particular the frameworks, are at the newest version (5.78 for kconfig and kdelibs4support) I have now rebuild all of plasma to the current state in git, installed it, recompiled digikam rc on this system, installed it, and still get hit by the same problem. Then I checked the appimage, and that one works. Comparing the versions, I see that: appimage home compiled -------------------------------------------- KDE Framewokrs 5.78 5.78 Qt 5.14.2 5.15.2 So I suppose this is either a bug in Qt (5.15) or some incompatibility between digikam and Qt 5.15. There is no compatibility issue with Qt 5.15 and digiKam. Here i use Linux CentOS system with an upgraded version of Qt 5.15.2 working fine under Plasma and Gnome desktop. Qt 5.15.2 is also used to make macOS and Windows bundles and it work as expected... I plan to upgrade AppImage with Qt 5.15.2 in the future Gillzs Caulier Ok, I created a new user and tried there - an there it is working. I will debug later on what is going on, but some file configuration file or so is kicking digikam into the off. It is possible that the KDE configuration file is damaged or the color scheme is defective or does not exist. But a color scheme set in digiKam and no longer available does not lead to a problem here. Maik Ok, I found the culprit. The following trivial change made digikam start up properly: [General Settings] Application Font=Noto Sans CJK JP Light,12,-1,5,25,0,0,0,0,0 -Application Style=fusion +Application Style=breeze Apply Sidebar Changes Directly=false I have no idea why there was "fusion" in there, guess I have selected it back then whenever. Anyway, this should *not* crash digikam ;-) Well, the application style "Fusion" is the standard for the AppImage and also in the Windows version, since "Breeze" is not available there. And the "Fusion" style works there without any problems, I can easily set the "Fusion" style here under my openSUSE KF5 Desktop. I suspect that something is wrong with your self-compiled KF5. Or is "Fusion" not available in your compiled Qt version? See if you could select the "Fusion" style in your compiled digiKam version in the digiKam Setup-> Miscellaneous-> Appearance. Maik Hi I can change the Widget Style to "Fusion" in the setup menu, and the layout changes - no error. Then I close digikam and restart, and it crashes again. Changing manually in digikamrc to Breeze makes it start again. 100% reproducible. So Fusion style should be here I guess, since there is a change in appearance when I select the FUsion widget style, but it fails on startup. Hopefully last comment. Today the breeze git contained the following commit: commit 12e42f014338cce6a6d706a222a2f4af4bbb49b2 (HEAD -> Plasma/5.21, origin/Plasma/5.21) Author: David Redondo <kde@david-redondo.de> Date: Tue Feb 9 08:54:34 2021 +0000 Clean up listener If the style is unloaded for example by an application dynamically switching styles, the listener was still around leading us to call into destroyed objects when the color scheme was changed. BUG:432660 (cherry picked from commit 5de36bd1381b1d755c8f2dd4b95b9758d3225b14) With this commit added to breeze, I can now change to Fusion and stay there and no crashes appear. So I would say, with today's breeze git update the issue can be closed. Hi Norbert, Great to read the issue is fixed. Note : it's always a bad idea to try to use Plasma from git/master in production. It's always an unstable workflow. Always use a n-1 or n-2 release to be sure that all is ready and tested. I close this file now. Best regards Gilles Caulier |