| Summary: | Digikam crash when starting | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | garymele |
| Component: | Metadata-Engine | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | caulier.gilles, metzpinguin |
| Priority: | NOR | Keywords: | drkonqi |
| Version First Reported In: | 6.3.0 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | FreeBSD | ||
| Latest Commit: | Version Fixed/Implemented In: | 7.0.0 | |
| Sentry Crash Report: | |||
Look like the crash come from Exiv2 shared library when internal XMP SDK is initialized... I recommend to report this problem to Exiv2 theam on Github to see if the problem have been already fixed. In all cases it's not a problem that digiKam team can solve directly. Gilles Caulier Same problem seen in Gnome project: https://gitlab.gnome.org/GNOME/gexiv2/issues/42 Gilles Caulier Git commit e423ab67611400ecfe30daeb3ffe3a28f53e817f by Maik Qualmann. Committed on 02/10/2019 at 20:26. Pushed by mqualmann into branch 'master'. replace Exiv2::Error with Exiv2::AnyError M +1 -1 core/libs/metadataengine/engine/metaengine.cpp M +1 -1 core/libs/metadataengine/engine/metaengine_comments.cpp M +1 -1 core/libs/metadataengine/engine/metaengine_data_p.cpp M +27 -27 core/libs/metadataengine/engine/metaengine_exif.cpp M +2 -2 core/libs/metadataengine/engine/metaengine_fileio.cpp M +6 -6 core/libs/metadataengine/engine/metaengine_gps.cpp M +21 -21 core/libs/metadataengine/engine/metaengine_iptc.cpp M +11 -11 core/libs/metadataengine/engine/metaengine_item.cpp M +6 -6 core/libs/metadataengine/engine/metaengine_p.cpp M +1 -1 core/libs/metadataengine/engine/metaengine_p.h M +4 -4 core/libs/metadataengine/engine/metaengine_previews.cpp M +22 -22 core/libs/metadataengine/engine/metaengine_xmp.cpp https://invent.kde.org/kde/digikam/commit/e423ab67611400ecfe30daeb3ffe3a28f53e817f @garymele It would be nice if you could compile the digiKam git/master version on FreeBSD and test if the problem is solved. Maik (In reply to Maik Qualmann from comment #4) > @garymele > It would be nice if you could compile the digiKam git/master version on > FreeBSD and test if the problem is solved. > > Maik Thanks for the update. I don't know how to do this outside of poudriere, so will wait for the update to be added to the FreeBSD ports. Gary Gilles, I think we can close this bug. FreeBSD automatic build no longer crashes when executing the test code. A nice side effect of your fight with MSVC. Maik hi Maik, yes, the complete cmake review for MSVC support has certainly removed some linking glitch that i discovered. At least 4 rules forced cmake to dupplicates symbols in digikam core, digikamdatabase, and digikamgui which can introduce dysfunctions at run-time. As MSVC is more sensible to these weird linking rules, this force me to review all cmake codes everywhere. I also checked the symbols inside shared libraries to see if duplicates symbols and now it's clean. The Q is : wy G++ do not crying in this kind of situation ? The good point too is the MacOS build which inherit of cmake code cleanning. As it's a BSD "like" OS (at some points), we have certainly killed dysfunctions under Apple. I plan later 7.0.0 to change the hierarchies in source code, using target libs as reference (aka utilities dir will be removed, and core/libs will host core, database, and gui sub directories with relevant code). But it's for 8.0.0 release not before. I already changed too much stuff in cmake, we need stabilization now. And i'm sure that compilation rules are enough safe for 7.0.0. Gilles |
Application: digikam (6.3.0) (Compiled from sources) Qt Version: 5.13.0 Frameworks Version: 5.62.0 Operating System: FreeBSD 12.0-RELEASE-p9 amd64 Distribution (Platform): FreeBSD Ports -- Information about the crash: - What I was doing when the application crashed: Starting Digikam from the menu. Crashes almost immediately. Problem appears to be in libexiv. The crash can be reproduced every time. -- Backtrace: Application: digiKam (digikam), signal: Segmentation fault (lldb) process attach --pid 9069 Process 9069 stopped Executable module set to "/usr/local/bin/digikam". Architecture set to: x86_64--freebsd12.0. (lldb) set term-width 200 (lldb) thread info thread #1: tid = 100437, 0x0000000803fbb84a libc.so.7`__sys_nanosleep + 10, name = 'digikam' (lldb) bt all * thread #1, name = 'digikam' * frame #0: 0x0000000803fbb84a libc.so.7`__sys_nanosleep + 10 frame #1: 0x000000080ad9617c libthr.so.3`___lldb_unnamed_symbol36$$libthr.so.3 + 44 frame #2: 0x0000000803f21e0b libc.so.7`_sleep + 59 frame #3: 0x000000080b6e853a libKF5Crash.so.5`___lldb_unnamed_symbol6$$libKF5Crash.so.5 + 1450 frame #4: 0x000000080b6e7c4c libKF5Crash.so.5`KCrash::defaultCrashHandler(int) + 1484 frame #5: 0x000000080ad994b6 libthr.so.3`___lldb_unnamed_symbol101$$libthr.so.3 + 214 frame #6: 0x000000080ad98a22 libthr.so.3`___lldb_unnamed_symbol82$$libthr.so.3 + 322 frame #7: 0x00007ffffffff003 frame #8: 0x0000000804c03b44 libexiv2.so.27`Exiv2::XmpParser::initialize(void(*)(void*bool), Exiv2::XmpParser::initialize) + 132 frame #9: 0x0000000800ad1514 libdigikamcore.so.6.3.0`Digikam::MetaEngine::initializeExiv2(void) + 36 frame #10: 0x0000000000207417 digikam`___lldb_unnamed_symbol4$$digikam + 4295 frame #11: 0x000000000020611b digikam`___lldb_unnamed_symbol1$$digikam + 283 thread #2, name = 'digikam:disk$0' frame #0: 0x000000080ada166c libthr.so.3`___lldb_unnamed_symbol182$$libthr.so.3 + 92 frame #1: 0x000000080ad9f388 libthr.so.3`___lldb_unnamed_symbol159$$libthr.so.3 + 504 frame #2: 0x000000081953944d i965_dri.so`___lldb_unnamed_symbol6415$$i965_dri.so + 477 frame #3: 0x0000000819539af9 i965_dri.so`___lldb_unnamed_symbol6422$$i965_dri.so + 25 frame #4: 0x000000080ad93776 libthr.so.3`___lldb_unnamed_symbol1$$libthr.so.3 + 326 thread #3, name = 'digikam' frame #0: 0x0000000803fce1ea libc.so.7`__sys_poll + 10 frame #1: 0x000000080ad96296 libthr.so.3`___lldb_unnamed_symbol38$$libthr.so.3 + 54 frame #2: 0x00000008075d7ea7 libglib-2.0.so.0`___lldb_unnamed_symbol117$$libglib-2.0.so.0 + 423 frame #3: 0x00000008075d7fb4 libglib-2.0.so.0`g_main_context_iteration + 100 frame #4: 0x0000000803ca1d9b libQt5Core.so.5`QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 139 frame #5: 0x0000000803c443de libQt5Core.so.5`QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 462 frame #6: 0x0000000803a6c4a9 libQt5Core.so.5`QThread::exec(void) + 169 frame #7: 0x000000080293eaa3 libQt5DBus.so.5`___lldb_unnamed_symbol12$$libQt5DBus.so.5 + 19 frame #8: 0x0000000803a6d4a4 libQt5Core.so.5`___lldb_unnamed_symbol209$$libQt5Core.so.5 + 228 frame #9: 0x000000080ad93776 libthr.so.3`___lldb_unnamed_symbol1$$libthr.so.3 + 326 (lldb) detach Process 9069 detached Possible duplicates by query: bug 412503, bug 412300, bug 412296, bug 412218, bug 412123. Reported using DrKonqi