Bug#1042376: digikam crashes with "Illegal instruction"

[Detlef Matthiessen]

Package: digikam
Version: 4:8.1.0-2
Severity: important

Dear Maintainer,

after updating digikam from 7.9.0-2 to 8.1.0-2, it crashes almost instantly:
dm@fluke:~$ digikam
Illegal instruction

The CPU I'm running this on is a rather old Quad Core:
dm@fluke:~$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 36 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Vendor ID: GenuineIntel
Model name: Intel(R) Core(TM)2 Quad CPU Q6700 @ 2.66GHz
CPU family: 6
Model: 15
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Stepping: 11
BogoMIPS: 5319.94
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep
mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe
syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid
aperfmperf pni dtes64 monitor ds_cpl vmx est
tm2 ssse3 cx16 xtpr pdcm lahf_lm pti tpr_shadow vnmi flexpriority vpid
dtherm
Virtualization features:
Virtualization: VT-x
(...)

If you need more information, please let me know.

Cheers,
Detlef

-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.3.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages digikam depends on:
ii digikam-data 4:8.1.0-2
ii digikam-private-libs 4:8.1.0-2
ii libc6 2.37-6
ii libgcc-s1 13.1.0-9
ii libkf5configcore5 5.107.0-1
ii libkf5coreaddons5 5.107.0-1
ii libkf5i18n5 5.107.0-1+b1
ii libmagick++-6.q16-8 8:6.9.11.60+dfsg-1.6
ii libqt5core5a 5.15.10+dfsg-2
ii libqt5gui5 5.15.10+dfsg-2
ii libqt5sql5 5.15.10+dfsg-2
ii libqt5sql5-mysql 5.15.10+dfsg-2
ii libqt5sql5-sqlite 5.15.10+dfsg-2
ii libqt5widgets5 5.15.10+dfsg-2
ii libstdc++6 13.1.0-9
ii perl 5.36.0-7

Versions of packages digikam recommends:
ii epiphany-browser [www-browser] 44.5-2
ii ffmpegthumbs 4:22.12.3-1
ii firefox-esr [www-browser] 115.0.2esr-1
ii konqueror [www-browser] 4:22.12.3-2
ii lynx [www-browser] 2.9.0dev.12-1
ii w3m [www-browser] 0.5.3+git20230121-2

Versions of packages digikam suggests:
ii breeze-icon-theme 4:5.107.0-1
pn digikam-doc <none>
ii systemsettings 4:5.27.5-2

-- no debconf information

--1690443662-eximdsn-30352056--

[Steven Robbins]

On Thursday, July 27, 2023 3:23:07 A.M. CDT Detlef Matthiessen wrote:

> after updating digikam from 7.9.0-2 to 8.1.0-2, it crashes almost instantly:
> dm@fluke:~$ digikam
> Illegal instruction
>

> (...)
>
> If you need more information, please let me know.

Thanks -- we'll need a backtrace from your system.

To obtain the trace, there are instructions here: https://wiki.debian.org/
HowToGetABacktrace

I got a trace using the following simple recipe:

apt install gdb
export DEBUGINFOD_URLS="https://debuginfod.debian.net"
gdb digikam
- answer 'y' when asked "Enable debuginfod for this session?"
run

Then reproduce your crash, and cut/paste the output into an email to this bug.

Thanks,
-Steve

[Detlef Matthiessen]

Hi Steve,

I've got:

Program received signal SIGILL, Illegal instruction.
0x00007ffff6cc20d3 in operator* (m1=..., m2=...) at /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h:642
Downloading source file /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h
642 /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h: Directory not empty.

HTH, Detlef

[Detlef Matthiessen]

I just realized that the last message was due to not having installed the related dev-packages on my system. So I did:
root@fluke:~# apt-get install qtbase5-dev

and now the complete error message reads:

Program received signal SIGILL, Illegal instruction.
0x00007ffff6cc20d3 in operator* (m1=..., m2=...) at /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h:642

642 QMatrix4x4 m = m1;

Cheers, Kay

[Detlef Matthiessen]

On 30.07.23 07:45, Detlef Matthiessen wrote:
> 642            QMatrix4x4 m = m1;

On a related note: a quick search for "digikam" and "642" yields the following bug report:
https://bugs.launchpad.net/ubuntu/+source/digikam/+bug/2000718
https://bugs.kde.org/show_bug.cgi?id=465548

Admittedly, I'm not familiar with the similarities of the instruction sets of an AMD Athlon II vs. my own Intel Q6700
(or more precise, their lack of complex instructions), but the problem sounds quite similar to mine.

FWIW, comment https://bugs.kde.org/show_bug.cgi?id=465548#c16 points to AppImages provided by the KDE team. 8.1.0 is no
longer available, but I was able to successfully start https://files.kde.org/digikam/digiKam-8.2.0-20230724T132443-x86-64.appimage
on my machine. So to me it looks as this bug probably already has been fixed upstream.

Cheers,
Detlef

[Steven Robbins]

Thanks for this. Oddly, the KDE bug notes indicate that the fix was put into
8.1.0 -- which is the version that this bug's originator reported on. So it's
unclear whether this is the same issue.

-Steve

[Detlef Matthiessen]

Hi Steve,

On 13.08.23 00:05, Steven Robbins wrote:

> There must be more than this?  Normally a backtrace shows a number of stack frames.  Did you type "bt" in the gdb propmpt after the crash?

Sorry, missed that part. My bad.

Program received signal SIGILL, Illegal instruction.

0x00007ffff6cc20a3 in operator* (m1=..., m2=...) at /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h:642

642 QMatrix4x4 m = m1;

(gdb) bt
#0 0x00007ffff6cc20a3 in operator* (m1=..., m2=...) at /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h:642
#1 0x00007ffff65b861d in __static_initialization_and_destruction_0 () at ./core/libs/video/qtav/utils/ColorTransform.cpp:59
#2 0x00007ffff7fcfe2e in call_init (env=0x7fffffffe0b8, argv=0x7fffffffe0a8, argc=1, l=<optimized out>) at ./elf/dl-init.c:70
#3 call_init (l=<optimized out>, argc=1, argv=0x7fffffffe0a8, env=0x7fffffffe0b8) at ./elf/dl-init.c:26
#4 0x00007ffff7fcff14 in _dl_init (main_map=0x7ffff7ffe2c0, argc=1, argv=0x7fffffffe0a8, env=0x7fffffffe0b8) at ./elf/dl-init.c:117
#5 0x00007ffff7fe5170 in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#6 0x0000000000000001 in ?? ()
#7 0x00007fffffffe3d3 in ?? ()
#8 0x0000000000000000 in ?? ()
(gdb)

Cheers, Detlef

[Detlef Matthiessen]

Hi Steve,

dm@fluke:/tmp$ g++ matrixtest.cc -I /usr/include/x86_64-linux-gnu/qt5 -msse2 -msse4.1 -fPIC -lQt5Core
dm@fluke:/tmp$ ./a.out
Hello

Hm.

Just to be sure, I also ran the attached executables, however they are giving me the same result:
dm@fluke:/tmp$ ./test-sse4
Hello
dm@fluke:/tmp$ ./test-no-sse4
Hello

dm@fluke:/tmp$ g++ --version
g++ (Debian 13.2.0-1) 13.2.0
(...)

However:
dm@fluke:~$ cpuid -1 -l1
CPU:
version information (1/eax):
processor type = primary processor (0)
family = 0x6 (6)
model = 0xf (15)
stepping id = 0xb (11)
extended family = 0x0 (0)
extended model = 0x0 (0)
(family synth) = 0x6 (6)
(model synth) = 0xf (15)
miscellaneous (1/ebx):
process local APIC physical ID = 0x1 (1)
maximum IDs for CPUs in pkg = 0x4 (4)
CLFLUSH line size = 0x8 (8)
brand index = 0x0 (0)
brand id = 0x00 (0): unknown
feature information (1/edx):
x87 FPU on chip = true
VME: virtual-8086 mode enhancement = true
DE: debugging extensions = true
PSE: page size extensions = true
TSC: time stamp counter = true
RDMSR and WRMSR support = true
PAE: physical address extensions = true
MCE: machine check exception = true
CMPXCHG8B inst. = true
APIC on chip = true
SYSENTER and SYSEXIT = true
MTRR: memory type range registers = true
PTE global bit = true
MCA: machine check architecture = true
CMOV: conditional move/compare instr = true
PAT: page attribute table = true
PSE-36: page size extension = true
PSN: processor serial number = false
CLFLUSH instruction = true
DS: debug store = true
ACPI: thermal monitor and clock ctrl = true
MMX Technology = true
FXSAVE/FXRSTOR = true
SSE extensions = true
SSE2 extensions = true
SS: self snoop = true
hyper-threading / multi-core supported = true
TM: therm. monitor = true
IA64 = false
PBE: pending break event = true
feature information (1/ecx):
PNI/SSE3: Prescott New Instructions = true
PCLMULDQ instruction = false
DTES64: 64-bit debug store = true
MONITOR/MWAIT = true
CPL-qualified debug store = true
VMX: virtual machine extensions = true
SMX: safer mode extensions = false
Enhanced Intel SpeedStep Technology = true
TM2: thermal monitor 2 = true
SSSE3 extensions = true
context ID: adaptive or shared L1 data = false
SDBG: IA32_DEBUG_INTERFACE = false
FMA instruction = false
CMPXCHG16B instruction = true
xTPR disable = true
PDCM: perfmon and debug = true
PCID: process context identifiers = false
DCA: direct cache access = false
SSE4.1 extensions = false
SSE4.2 extensions = false
x2APIC: extended xAPIC support = false
MOVBE instruction = false
POPCNT instruction = false
time stamp counter deadline = false
AES instruction = false
XSAVE/XSTOR states = false
OS-enabled XSAVE/XSTOR = false
AVX: advanced vector extensions = false
F16C half-precision convert instruction = false
RDRAND instruction = false
hypervisor guest status = false


Regards,

Detlef

[Steven Robbins]

On Monday, August 14, 2023 1:25:23 A.M. CDT Detlef Matthiessen wrote:

>    Hi Steve,

>

>    right after I replied to the bug report, I noticed:

>

> dm@fluke:/tmp$ diff test-no-sse4 test-sse4

> dm@fluke:/tmp$

>

>    Can you confirm that the attached binaries are identical?

Nice catch.  They are identical.  I repeated the compilations this morning with/without -msse4.1 and the result is indeed identical.  In fact, it is the same when I omit *both* -msse2 and -msse4.1.

I notice also that nowhere does the code reference the matrix computed.  I wondered whether all that code was being optimized away -- so I added code to reference it:

std::cout << "Element[0][0] = " << yuv2rgb_bt601(0,0) << "\n";

However, there is no change: the binary is identical regardless of the -m options. 

So I'm back to square 1, very confused by your crash.

-Steve

[Steven Robbins]

On Monday, August 14, 2023 8:52:14 A.M. CDT Steven Robbins wrote:

> So I'm back to square 1, very confused by your crash.

I have made a change to digikam and uploaded 8.1.0-3 last night. It should
avoid calling SSE 4 functions if only SSE 2 is detected. I'd appreciate if
you could try it out and report back to this bug whether it fixes your crash or
not.

It's a bit of a shot in the dark since it doesn't affect the specific function
pointed at in your back trace.

Best,
-Steve

[Detlef Matthiessen]

Hi Steve,

I'm afraid, it doesn't prevent digikam from crashing.

Here is what I did (after fetching the latest updates from "testing" this morning):

root@fluke:/etc/apt# sed -i 's/trixie/sid/' sources.list
root@fluke:/etc/apt# apt-get update
Get:1 http://ftp.de.debian.org/debian sid InRelease [210 kB]
(...)

root@fluke:/etc/apt# apt-get install digikam
(...)
The following additional packages will be installed:
digikam-data digikam-private-libs
Suggested packages:
digikam-doc
The following packages will be upgraded:
digikam digikam-data digikam-private-libs
3 upgraded, 0 newly installed, 0 to remove and 212 not upgraded.
Need to get 19.2 MB of archives.
After this operation, 2,048 B disk space will be freed.
Do you want to continue? [Y/n]
Get:1 http://ftp.de.debian.org/debian sid/main amd64 digikam amd64 4:8.1.0-3 [100 kB]
Get:2 http://ftp.de.debian.org/debian sid/main amd64 digikam-private-libs amd64 4:8.1.0-3 [9,949 kB]
Get:3 http://ftp.de.debian.org/debian sid/main amd64 digikam-data all 4:8.1.0-3 [9,121 kB]
Fetched 19.2 MB in 2s (12.0 MB/s)
Reading changelogs... Done
(Reading database ... 475773 files and directories currently installed.)
Preparing to unpack .../digikam_4%3a8.1.0-3_amd64.deb ...
Unpacking digikam (4:8.1.0-3) over (4:8.1.0-2+b1) ...
Preparing to unpack .../digikam-private-libs_4%3a8.1.0-3_amd64.deb ...
Unpacking digikam-private-libs (4:8.1.0-3) over (4:8.1.0-2+b1) ...
Preparing to unpack .../digikam-data_4%3a8.1.0-3_all.deb ...
Unpacking digikam-data (4:8.1.0-3) over (4:8.1.0-2) ...
Setting up digikam-private-libs (4:8.1.0-3) ...
Setting up digikam-data (4:8.1.0-3) ...
Setting up digikam (4:8.1.0-3) ...
(...)

dm@fluke:~$ digikam
Illegal instruction

dm@fluke:~$ export DEBUGINFOD_URLS="https://debuginfod.debian.net"
dm@fluke:~$ gdb digikam
(...)

Program received signal SIGILL, Illegal instruction.

0x00007ffff6cc2103 in operator* (m1=..., m2=...) at /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h:642

642 QMatrix4x4 m = m1;
(gdb) bt

#0 0x00007ffff6cc2103 in operator* (m1=..., m2=...) at /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h:642

#1 0x00007ffff65b861d in __static_initialization_and_destruction_0 () at ./core/libs/video/qtav/utils/ColorTransform.cpp:59
#2 0x00007ffff7fcfe2e in call_init (env=0x7fffffffe0b8, argv=0x7fffffffe0a8, argc=1, l=<optimized out>) at ./elf/dl-init.c:70
#3 call_init (l=<optimized out>, argc=1, argv=0x7fffffffe0a8, env=0x7fffffffe0b8) at ./elf/dl-init.c:26
#4 0x00007ffff7fcff14 in _dl_init (main_map=0x7ffff7ffe2c0, argc=1, argv=0x7fffffffe0a8, env=0x7fffffffe0b8) at ./elf/dl-init.c:117
#5 0x00007ffff7fe5170 in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#6 0x0000000000000001 in ?? ()

#7 0x00007fffffffe3d4 in ?? ()

#8 0x0000000000000000 in ?? ()

Not sure if my approach is the preferred way to test something across different branches, though. I didn't want to switch my entire system to "sid" (this is my main machine, after all :) ). Hope that's OK. If there's a better way of testing your version, please let me know.

I'm willing to repeat the test once 8.1.0-3 lands in "testing" although I'm not expecting the result to be different.

Cheers,

Detlef

[Steven Robbins]

On Saturday, August 19, 2023 11:53:35 A.M. CDT you wrote:
> Hi Steve,
>
> I'm afraid, it doesn't prevent digikam from crashing.
>
> Here is what I did (after fetching the latest updates from "testing" this
> morning):

[ ... ]

> Not sure if my approach is the preferred way to test something across
> different branches, though. I didn't want to switch my entire system to
> "sid" (this is my main machine, after all :) ). Hope that's OK. If there's
> a better way of testing your version, please let me know.

The testing approach is fine. Thanks for this.

Given the gdb stack trace, this result is what I expected. I don't understand
what the illegal instruction is at that address. I have two ideas at this
point.

1. Test a build without SSE4. If you feel up to it, this would be easiest to
do on your machine because the build-time detection should simply work fine.
If you have sufficient time and interest, please look at https://
www.linuxfordevices.com/tutorials/debian/build-packages-from-source

If you aren't able to build from sources, let me know. The alternative is for
me to build it here after hacking the sources to disable SSE4 detection.


2. Dig further with the debugger to understand what the illegal instruction
is. I may be completely wrong in assuming it is an SSE4 instruction --
particularly given the fact that the test code we discussed August 13/14
builds the same with/without the -msse4.1 flag. If you are handy with gdb you
can probably dig into the assembly and figure out what the instruction is.

Regards,
-Steve

[Detlef Matthiessen]

On 19.08.23 22:00, Steven Robbins wrote:
> 1. Test a build without SSE4.

I built 8.1.0-2 from sources (which took 70 minutes on my machine,
btw), removed the version from "sid" that I had installed the other day
and then did:
root@fluke:~# dpkg -i digikam_8.1.0-2_amd64.deb
digikam-data_8.1.0-2_all.deb digikam-private-libs_8.1.0-2_amd64.deb

Lo and behold! It works flawlessly and is even able to show videos
(something that the 8.2.0 AppImage from KDE, that I had been using in
the meantime
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042376#25), failed at).

> 2. Dig further with the debugger to understand what the illegal instruction
> is. I may be completely wrong in assuming it is an SSE4 instruction --
> particularly given the fact that the test code we discussed August 13/14
> builds the same with/without the -msse4.1 flag. If you are handy with gdb you
> can probably dig into the assembly and figure out what the instruction is.

Now that I'm in the possession of working packages for digikam, I
could volunteer to assist you in finding out the root cause of the crash
(which I assume probably affects only a small number of users anyway).
However, it has been literally decades that I've done any serious
programming in C/C++. Any hints on how to use gdb in this regard and
what to look for would be highly appreciated.

Kind regards,

Detlef

[Karine Crèvecœur]

Hi,

I read the thread for this bug with attention. I use debian/sid.
Digikam version is 8.1.0-3 from debian repository.

I encounter the same bug, on my pretty old dual core :

$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit

Address sizes: 48 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Vendor ID: AuthenticAMD
Model name: AMD Athlon(tm) II X2 220 Processor
CPU family: 16
Model: 6
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 1
Stepping: 3
CPU(s) scaling MHz: 88%
CPU max MHz: 2800.0000
CPU min MHz: 800.0000
BogoMIPS: 5586.12
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate vmmcall npt lbrv svm_lock nrip_save
…

$ cpuid -1 -l1

CPU:
version information (1/eax):
processor type = primary processor (0)

family = 0xf (15)
model = 0x6 (6)
stepping id = 0x3 (3)
extended family = 0x1 (1)

extended model = 0x0 (0)

(family synth) = 0x10 (16)
(model synth) = 0x6 (6)

miscellaneous (1/ebx):
process local APIC physical ID = 0x1 (1)

maximum IDs for CPUs in pkg = 0x2 (2)

CLFLUSH line size = 0x8 (8)
brand index = 0x0 (0)
brand id = 0x00 (0): unknown
feature information (1/edx):
x87 FPU on chip = true
VME: virtual-8086 mode enhancement = true
DE: debugging extensions = true
PSE: page size extensions = true
TSC: time stamp counter = true
RDMSR and WRMSR support = true
PAE: physical address extensions = true
MCE: machine check exception = true
CMPXCHG8B inst. = true
APIC on chip = true
SYSENTER and SYSEXIT = true
MTRR: memory type range registers = true
PTE global bit = true
MCA: machine check architecture = true
CMOV: conditional move/compare instr = true
PAT: page attribute table = true
PSE-36: page size extension = true
PSN: processor serial number = false
CLFLUSH instruction = true

DS: debug store = false
ACPI: thermal monitor and clock ctrl = false

MMX Technology = true
FXSAVE/FXRSTOR = true
SSE extensions = true
SSE2 extensions = true

SS: self snoop = false

hyper-threading / multi-core supported = true

TM: therm. monitor = false
IA64 = false
PBE: pending break event = false

feature information (1/ecx):
PNI/SSE3: Prescott New Instructions = true
PCLMULDQ instruction = false

DTES64: 64-bit debug store = false
MONITOR/MWAIT = true
CPL-qualified debug store = false
VMX: virtual machine extensions = false

SMX: safer mode extensions = false

Enhanced Intel SpeedStep Technology = false
TM2: thermal monitor 2 = false
SSSE3 extensions = false

context ID: adaptive or shared L1 data = false
SDBG: IA32_DEBUG_INTERFACE = false
FMA instruction = false
CMPXCHG16B instruction = true

xTPR disable = false
PDCM: perfmon and debug = false

PCID: process context identifiers = false
DCA: direct cache access = false
SSE4.1 extensions = false
SSE4.2 extensions = false
x2APIC: extended xAPIC support = false
MOVBE instruction = false

POPCNT instruction = true

time stamp counter deadline = false
AES instruction = false
XSAVE/XSTOR states = false
OS-enabled XSAVE/XSTOR = false
AVX: advanced vector extensions = false
F16C half-precision convert instruction = false
RDRAND instruction = false
hypervisor guest status = false

I run gdb to obtain a backtrace :
$ export DEBUGINFOD_URLS="https://debuginfod.debian.net"
$ gdb digikam
(gdb) run

Program received signal SIGILL, Illegal instruction.
0x00007ffff6cc2103 in operator* (m1=..., m2=...) at /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h:642
642 QMatrix4x4 m = m1;
(gdb) bt

#0 0x00007ffff6cc2103 in operator*(QMatrix4x4 const&, QMatrix4x4 const&) (m1=..., m2=...) at /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h:642
#1 0x00007ffff65b861d in __static_initialization_and_destruction_0() () at ./core/libs/video/qtav/utils/ColorTransform.cpp:59
#2 0x00007ffff7fcfe2e in call_init (env=0x7fffffffdf58, argv=0x7fffffffdf48, argc=1, l=<optimized out>) at ./elf/dl-init.c:70
#3 call_init (l=<optimized out>, argc=1, argv=0x7fffffffdf48, env=0x7fffffffdf58) at ./elf/dl-init.c:26
#4 0x00007ffff7fcff14 in _dl_init (main_map=0x7ffff7ffe2c0, argc=1, argv=0x7fffffffdf48, env=0x7fffffffdf58) at ./elf/dl-init.c:117
#5 0x00007ffff7fe5170 in _dl_start_user () at /lib64/ld-linux-x86-64.so.2
#6 0x0000000000000001 in ()
#7 0x00007fffffffe376 in ()
#8 0x0000000000000000 in ()
(gdb) disassemble
…
0x00007ffff6cc20e8 <+136>: movaps %xmm8,%xmm4
0x00007ffff6cc20ec <+140>: mov %edx,-0x4c(%rsp)
0x00007ffff6cc20f0 <+144>: mov 0x38(%r9),%rdx
0x00007ffff6cc20f4 <+148>: mulss %xmm5,%xmm4
0x00007ffff6cc20f8 <+152>: movss 0x3c(%r9),%xmm10
0x00007ffff6cc20fe <+158>: movq %r10,%xmm7
=> 0x00007ffff6cc2103 <+163>: extractps $0x3,%xmm12,%r11d
0x00007ffff6cc210a <+170>: mov %rdx,%r15
0x00007ffff6cc210d <+173>: mov 0x28(%rax),%rdx
0x00007ffff6cc2111 <+177>: movshdup %xmm7,%xmm7
0x00007ffff6cc2115 <+181>: extractps $0x2,%xmm12,%edi
0x00007ffff6cc211c <+188>: mulss %xmm6,%xmm2
0x00007ffff6cc2120 <+192>: movq %rdx,%xmm15
0x00007ffff6cc2125 <+197>: mov %rdx,-0x40(%rsp)
…

The instruction that leads to crash seems to be "extractps".According
to <https://www.felixcloutier.com/x86/extractps> it is an instruction
related to SSE4.1.

I had to rebuild digikam from the package source with debuild as follow
to get digikam working again:
$ CFLAGS=-march=native CXXFLAGS=-march=native debuild -b -us -uc

Maybe I could try to build with -march=x86-64. That should work.

Well, I hope my investigation can help to solve this bug.

Cheers.
--
Karine

[Steven Robbins]

On Sunday, August 27, 2023 12:43:31 P.M. CDT Karine Crèvecœur wrote:


> (gdb) disassemble
> …
> 0x00007ffff6cc20e8 <+136>: movaps %xmm8,%xmm4
> 0x00007ffff6cc20ec <+140>: mov %edx,-0x4c(%rsp)
> 0x00007ffff6cc20f0 <+144>: mov 0x38(%r9),%rdx
> 0x00007ffff6cc20f4 <+148>: mulss %xmm5,%xmm4
> 0x00007ffff6cc20f8 <+152>: movss 0x3c(%r9),%xmm10
> 0x00007ffff6cc20fe <+158>: movq %r10,%xmm7
> => 0x00007ffff6cc2103 <+163>: extractps $0x3,%xmm12,%r11d
> 0x00007ffff6cc210a <+170>: mov %rdx,%r15
> 0x00007ffff6cc210d <+173>: mov 0x28(%rax),%rdx
> 0x00007ffff6cc2111 <+177>: movshdup %xmm7,%xmm7
> 0x00007ffff6cc2115 <+181>: extractps $0x2,%xmm12,%edi
> 0x00007ffff6cc211c <+188>: mulss %xmm6,%xmm2
> 0x00007ffff6cc2120 <+192>: movq %rdx,%xmm15
> 0x00007ffff6cc2125 <+197>: mov %rdx,-0x40(%rsp)
> …
>
> The instruction that leads to crash seems to be "extractps".According
> to <https://www.felixcloutier.com/x86/extractps> it is an instruction
> related to SSE4.1.

Thank you! That is exactly what I needed to know.

So it is clear that some folks need a build with SSE4 disabled. But SSE2 is
supported on the machines of you and the original reporter so I'll try first
with SSE2 but not SSE4.

The remaining issue is: I need to figure a way to build two binary packages
from the source. The other alternative is to disable SSE4 for everyone but I
have no idea what performance impact that might have.

Regards,
-Steve

[Andreas Brogle]

Will this bug ever been fixed?
7 of 11 machines here are fast enough for digikam, but they all are
exiting with "Illegal Instruction".
I guess it doesn't care if SSE4 is enabled or not, but older hardware
could be upcycled without that.

With best regards, Andreas