SUMMARY The following is a downstream bug reported on Launchpad at https://launchpad.net/bugs/2000718, more logs available there. Filer's name is Graeme Hewson *** The crash happens early in the initialisation, since it occurs just trying to display the version: $ digikam --version Illegal instruction (core dumped) $ Gdb shows the failing instruction: $ gdb digikam GNU gdb (Ubuntu 12.1-3ubuntu2) 12.1 Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from digikam... This GDB supports auto-downloading debuginfo from the following URLs: https://debuginfod.ubuntu.com Enable debuginfod for this session? (y or [n]) y Debuginfod has been enabled. To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit. Reading symbols from /home/ghewson/.cache/debuginfod_client/c793f63692bc8f2f3ec63f47803ccc5398e78dcb/debuginfo... (gdb) r Starting program: /usr/bin/digikam [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffd13966c0 (LWP 319127)] Thread 1 "digikam" received signal SIGILL, Illegal instruction. 0x00007ffff6c748b4 in operator* (m1=..., m2=...) at /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h:642 642 /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h: Directory not empty. (gdb) disas /s $pc-10,+20 Dump of assembler code from 0x7ffff6c748aa to 0x7ffff6c748be: /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h: 642 in /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h 643 in /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h 644 in /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h 645 in /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h 646 in /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h 647 in /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h 648 in /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h 649 in /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h 0x00007ffff6c748aa <_ZmlRK10QMatrix4x4S1_+154>: sub %dh,%bl 0x00007ffff6c748ac <_ZmlRK10QMatrix4x4S1_+156>: movlhps %xmm0,%xmm7 642 in /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h 0x00007ffff6c748af <_ZmlRK10QMatrix4x4S1_+159>: movups 0x30(%r9),%xmm0 => 0x00007ffff6c748b4 <_ZmlRK10QMatrix4x4S1_+164>: extractps $0x2,%xmm12,%r11d 0x00007ffff6c748bb <_ZmlRK10QMatrix4x4S1_+171>: extractps $0x1,%xmm12,%edi End of assembler dump. (gdb) EXTRACTPS is part of the SSE4.1 instruction set, which is not supported by AMD Athlon II Regor processors (or any other in the family, I believe): they support only the SSE4a instruction group. References: https://en.wikipedia.org/wiki/SSE4#SSE4.1 https://en.wikipedia.org/wiki/List_of_AMD_Athlon_II_processors#%22Regor%22_(C2/C3,_45_nm,_Dual-core) ProblemType: Bug DistroRelease: Ubuntu 22.10 Package: digikam 4:8.0.0~git20221002-0ubuntu1 ProcVersionSignature: Ubuntu 5.19.0-26.27-generic 5.19.7 Uname: Linux 5.19.0-26-generic x86_64 ApportVersion: 2.23.1-0ubuntu3 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Thu Dec 29 10:41:20 2022 EcryptfsInUse: Yes InstallationDate: Installed on 2015-09-08 (2668 days ago) InstallationMedia: Kubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422) SourcePackage: digikam UpgradeStatus: Upgraded to kinetic on 2022-10-25 (64 days ago) *** STEPS TO REPRODUCE Per the above report, it fails upon execution with illegal instruction. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Ubuntu 22.10 KDE Plasma Version: 5.25 or 5.26 Qt Version: 5.15
Bug originally filed against Kubuntu: https://bugs.launchpad.net/ubuntu/+source/digikam/+bug/2000718 Crash occurs in /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h with EXTRACTPS instruction. This is part of the SSE4.1 instruction set, which is not supported by AMD Athlon II processors. See original bug report for more details.
Ok, this is not a digiKam problem. There is a problem with compiling the Qt library. If it doesn't crahes with other programs, it's because they don't use QMatrix4x4. Someone enabled an optimization when compiling the Qt packages that is not supported on all processors. Report it to the creators of the Qt packages on your system. Maik
(In reply to Maik Qualmann from comment #2) > Ok, this is not a digiKam problem. There is a problem with compiling the Qt > library. If it doesn't crahes with other programs, it's because they don't > use QMatrix4x4. Someone enabled an optimization when compiling the Qt > packages that is not supported on all processors. Report it to the creators > of the Qt packages on your system. > > Maik Well, if that's the case then every single Qt application would be dying on his system, which is not the case. Adding Dmitry Shachnev to this conversation as we're officially outside my realm of expertise.
Inspecting the code with another, it seems as though you've got an issue here: https://invent.kde.org/graphics/digikam/-/blob/master/core/cmake/macros/MacroSSE.cmake#L40 You're getting the SSE info from the host as opposed to building generically or using -march=native. I'd consider this rather odd and setting it so that it fails on processors other than the one it's building on. In other words, this is bad practice.
Yes, we may have to reconsider that. But it only affects our internal QtAV. It affects the function to copy frames, but it is also checked at runtime whether SSE4 is actually available. Maik
Any news here? digikam just crashes on many user systems just because it was built on hardware which supported SSE4.1.
You can set -DSSE4_1_FOUND=OFF at configure time.
(In reply to Antonio Rojas from comment #7) > You can set -DSSE4_1_FOUND=OFF at configure time. As a workaround that's certainly possible, but it's not a proper solution. This will break e.g. once checks for AVX are added.
QtAV upstream does this correctly already: src/utils/CopyFrame_SSE4.cpp is built with -msse4.1, src/utils/CopyFrame_SSE2.cpp is built with -msse2 and src/utils/GPUMemCopy.cpp decides during runtime which of those to call. Unfortunately digikam reimplemented everything in custom cmake, which broke this.
As explained here : https://stackoverflow.com/questions/6901369/how-to-detect-sse-availability-in-cmake The VS code from github include the OptimizeForArchitecture.cmake, which come from KDE in fact. I tried to see the file is included in Extra Cmake Module from KF5 framework, but i don't find it. Perhaps it come from another KDE project. OptimizeForArchitecture.cmake could be used in place to handle and setup compilation with CPU supporting SSE instructions. Gilles
To Erich Eickmeyer comment 4: This is how original QtAV deal with SSE instructions. I only port all QtAV rules to a modern CMake implementation. C++ codes still the same. Gilles Caulier
(In reply to caulier.gilles from comment #11) > To Erich Eickmeyer comment 4: > > This is how original QtAV deal with SSE instructions. I only port all QtAV > rules to a modern CMake implementation. C++ codes still the same. > > Gilles Caulier If you have ported the QtAV rules into your code, then by that logic it is a bug in your code.
To Fabian Vogt comment 9: This is completly wrong. Both SSE 2 or 4 are detected, definition are set and ALSO the CPU flags. Read well the cmake code AND the cmake Media player configuration report done before the compilation : 1/ SSE detection : https://invent.kde.org/graphics/digikam/-/blob/master/core/cmake/rules/RulesMediaPlayer.cmake#L43 2/ SSE compiler flags + report of detection : https://invent.kde.org/graphics/digikam/-/blob/master/core/cmake/rules/RulesMediaPlayer.cmake#L128 3/ SSE definitions for the code compilation : https://invent.kde.org/graphics/digikam/-/blob/master/core/cmake/rules/RulesMediaPlayer.cmake#L417 4/ Report of compiler flags passed to QtAV code : https://invent.kde.org/graphics/digikam/-/blob/master/core/cmake/rules/RulesMediaPlayer.cmake#L556 5/ Compilation of QtAV SSE code depending of the cmake detection : https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/video/qtav/CMakeLists.txt#L144 6/ Definitions and flags passed to compile QtAV code depending of SSE detection : https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/video/qtav/CMakeLists.txt#L457 I double check the cmake configuration report and the compilation rules with "export VERBOSE=1" to see if code is well compile with defintions and flags, and all is fine. I think the error can be located in the cmake code here : https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/video/qtav/CMakeLists.txt#L150 These rules compile SSE4 code if SSE4 is detected, else SSE2 code if SSE2 is detected. it never compile both at the same time, so there is a risk to switch to a void(void) function not compiled at run-time when different architecture is used. Gilles Caulier
In fact the wrong logic can be seen in C++ code : https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/video/qtav/utils/GPUMemCopy.cpp#L108 The cache used to copy with SSE is initialized if at least SSE2 is detected. there is nothing done with SSE4. But SSE2 always exist if SSE4 is detected. In cmake we expect SSE2 or SSE4, not Both at same time: https://invent.kde.org/graphics/digikam/-/blob/master/core/cmake/rules/RulesMediaPlayer.cmake#L417 Gilles Caulier
Git commit 799953eef9f43fb38d781cff8bea8eb201bb78bb by Gilles Caulier. Committed on 26/05/2023 at 07:09. Pushed by cgilles into branch 'master'. Handle SSE2 and SSE4 combination, not as separated support while compiling QtAV code M +12 -5 core/cmake/rules/RulesMediaPlayer.cmake M +3 -1 core/libs/video/qtav/CMakeLists.txt https://invent.kde.org/graphics/digikam/-/commit/799953eef9f43fb38d781cff8bea8eb201bb78bb
Hi all, The current code of future 8.1.0 is patched. I recompiled the Linux AppImage pre-release to see if problem is reproducible (it's compiled under Ubuntu 18.04). Files are there : https://files.kde.org/digikam/ Please check at least to see if problem still reproducible with this bundle on your computer. Best Gilles Caulier
Note : here only Intel CPU based computer are available to test. So i cannot validate myself the fixes. Gilles Caulier
I'm the original reporter of the problem. I'm pleased to say the AppImage works fine on an AMD Athlon II under Kubuntu 23.04.