Is it compiled with Clang, does the backtrace look like this? It seems to crash far beyond digiKam.

Please create a GDB backtrace as described here: https://www.digikam.org/contribute/

Please test with the current AppImage if the issue can be reproduced: https://files.kde.org/digikam/digikam-6.2.0-git-20190618T151249-qtwebkit-x86-64.appimage

Maik

After the libs in the backtrace it is digiKam-6.1.0.

Maik

After the backtrace, it looks like the Fedora OpenCV packages are compiled with OpenCL. Please post the output for "opencv_version --hw --opencl".

Maik

opencv_version --hw --opencl
3.4.4
[ INFO:0] Initialize OpenCL runtime...
OpenCL Platforms: 
    Intel Gen OCL Driver
        iGPU: Intel(R) HD Graphics Kabylake Halo GT2 (OpenCL 2.0 beignet 1.3)
    Clover
        dGPU: AMD VEGAM (DRM 3.30.0, 5.1.15-300.fc30.x86_64, LLVM 8.0.0) (OpenCL 1.1 Mesa 19.0.8)
    Portable Computing Language
        CPU: pthread-Intel(R) Core(TM) i7-8809G CPU @ 3.10GHz (OpenCL 1.2 pocl HSTR: pthread-x86_64-unknown-linux-gnu-skylake)
Current OpenCL device: 
    Type = iGPU
    Name = Intel(R) HD Graphics Kabylake Halo GT2
    Version = OpenCL 2.0 beignet 1.3
    Driver version = 1.3
    Address bits = 32
    Compute units = 24
    Max work group size = 512
    Local memory size = 64 KB
    Max memory allocation size = 3 GB
    Double support = No
    Host unified memory = Yes
    Device extensions:
        cl_khr_global_int32_base_atomics
        cl_khr_global_int32_extended_atomics
        cl_khr_local_int32_base_atomics
        cl_khr_local_int32_extended_atomics
        cl_khr_byte_addressable_store
        cl_khr_3d_image_writes
        cl_khr_image2d_from_buffer
        cl_khr_depth_images
        cl_khr_spir
        cl_khr_icd
        cl_intel_accelerator
        cl_intel_subgroups
        cl_intel_subgroups_short
        cl_khr_gl_sharing
        cl_khr_fp16
    Has AMD Blas = No
    Has AMD Fft = No
    Preferred vector width char = 16
    Preferred vector width short = 8
    Preferred vector width int = 4
    Preferred vector width long = 2
    Preferred vector width float = 4
    Preferred vector width double = 0
OpenCV's HW features list:
    ID=  1 (MMX) -> ON
    ID=  2 (SSE) -> ON
    ID=  3 (SSE2) -> ON
    ID=  4 (SSE3) -> ON
    ID=  5 (SSSE3) -> ON
    ID=  6 (SSE4.1) -> ON
    ID=  7 (SSE4.2) -> ON
    ID=  8 (POPCNT) -> ON
    ID=  9 (FP16) -> ON
    ID= 10 (AVX) -> ON
    ID= 11 (AVX2) -> ON
    ID= 12 (FMA3) -> ON
    ID= 13 (AVX512F) -> N/A
    ID= 14 (AVX512BW) -> N/A
    ID= 15 (AVX512CD) -> N/A
    ID= 16 (AVX512DQ) -> N/A
    ID= 17 (AVX512ER) -> N/A
    ID= 18 (AVX512IFMA) -> N/A
    ID= 19 (AVX512PF) -> N/A
    ID= 20 (AVX512VBMI) -> N/A
    ID= 21 (AVX512VL) -> N/A
    ID=100 (NEON) -> N/A
    ID=200 (VSX) -> N/A
    ID=256 (AVX512-SKX) -> N/A
Total available: 12

Yes, OpenCL hardware acceleration is active. I'm sure it's the cause of the crash. Here on openSUSE Tumbleweed (developer version) OpenCL is disabled. We at digiKam can not change anything from here. My recommendation to Fedora would be to offer OpenCV packages both with and without OpenCL.

Maik

Ok I'll cross reference this bug to the Fedora bug that I raised.

I'll also update this if I find a solution.

Thanks for your help.

Just out of interest why would hardware acceleration cause it to break?

It is probably possible since OpenCV 3 to disable OpenCL during runtime. I will test it.

Maik

Created attachment 121329 [details]
disableOpenCL.patch

This is a first test patch to disable OpenCL at runtime. This must be done in every thread. At present, students are working on improving the face engine. In order not to hinder their work on the code, I will apply the patch later. OpenSUSE did not really disable OpenCL, just did not install the required OpenCL packages. I could not reproduce a crash here with my AMD GPU. I think Fedora solved it similarly. Uninstall the appropriate OpenCL packages for testing.

Maik

I confirm that removing OpenCL packages form my system does indeed stop the crash.

Ok, thanks for the feedback. So the OpenCL driver for your Intel hardware is broken. Here with the AMD GPU I can not reproduce a crash. I will do a benchmark to see how much the use of OpenCL actually brings. I will extend the patch and make the deactivation of OpenCL configurable.

Maik

Maik,

The patch is fine for me and canbe applied to master.

I CC Thanh for information...

Gilles

So I reinstalled the OpenCL package and now when I run I get the AMD GPU as the default GPU device which is on this system as well now it runs fine. What's annoying is why is the AMD GPU now the default and how this happen by just dnf remove, dnf install. The system does have an intel GPU and an AMD VEGAM GPU on the CPU (i7-8809G). 

Ill have to do a bit of reading up on how to configure OpenCL and how it works. Must be able to select the device some how.

So this is really a bug with how OpenCL is setup more that anything, hopefully this will help anyone with the same issue.


opencv_version --hw --opencl
3.4.4
[ INFO:0] Initialize OpenCL runtime...
OpenCL Platforms: 
    Clover
        dGPU: AMD VEGAM (DRM 3.30.0, 5.1.15-300.fc30.x86_64, LLVM 8.0.0) (OpenCL 1.1 Mesa 19.0.8)
    Portable Computing Language
        CPU: pthread-Intel(R) Core(TM) i7-8809G CPU @ 3.10GHz (OpenCL 1.2 pocl HSTR: pthread-x86_64-unknown-linux-gnu-skylake)
Current OpenCL device: 
    Type = dGPU
    Name = AMD VEGAM (DRM 3.30.0, 5.1.15-300.fc30.x86_64, LLVM 8.0.0)
    Version = OpenCL 1.1 Mesa 19.0.8
    Driver version = 19.0.8
    Address bits = 64
    Compute units = 24
    Max work group size = 256
    Local memory size = 32 KB
    Max memory allocation size = 3 GB 204 MB 819 KB 204 B
    Double support = Yes
    Host unified memory = No
    Device extensions:
        cl_khr_byte_addressable_store
        cl_khr_global_int32_base_atomics
        cl_khr_global_int32_extended_atomics
        cl_khr_local_int32_base_atomics
        cl_khr_local_int32_extended_atomics
        cl_khr_int64_base_atomics
        cl_khr_int64_extended_atomics
        cl_khr_fp64
        cl_khr_fp16
    Has AMD Blas = No
    Has AMD Fft = No
    Preferred vector width char = 16
    Preferred vector width short = 8
    Preferred vector width int = 4
    Preferred vector width long = 2
    Preferred vector width float = 4
    Preferred vector width double = 2
OpenCV's HW features list:
    ID=  1 (MMX) -> ON
    ID=  2 (SSE) -> ON
    ID=  3 (SSE2) -> ON
    ID=  4 (SSE3) -> ON
    ID=  5 (SSSE3) -> ON
    ID=  6 (SSE4.1) -> ON
    ID=  7 (SSE4.2) -> ON
    ID=  8 (POPCNT) -> ON
    ID=  9 (FP16) -> ON
    ID= 10 (AVX) -> ON
    ID= 11 (AVX2) -> ON
    ID= 12 (FMA3) -> ON
    ID= 13 (AVX512F) -> N/A
    ID= 14 (AVX512BW) -> N/A
    ID= 15 (AVX512CD) -> N/A
    ID= 16 (AVX512DQ) -> N/A
    ID= 17 (AVX512ER) -> N/A
    ID= 18 (AVX512IFMA) -> N/A
    ID= 19 (AVX512PF) -> N/A
    ID= 20 (AVX512VBMI) -> N/A
    ID= 21 (AVX512VL) -> N/A
    ID=100 (NEON) -> N/A
    ID=200 (VSX) -> N/A
    ID=256 (AVX512-SKX) -> N/A
Total available: 12

I found this:

https://answers.opencv.org/question/147932/how-to-change-opencl-device/

Maik

digiKam 7.0.0-beta1 is ready for testing :

https://download.kde.org/unstable/digikam/

In this release, the Faces Management pipeline receive a lots of patches to increase stability and prevent crash. You can see the long story on this bugzilla file :

https://bugs.kde.org/show_bug.cgi?id=399923

Please test the Faces Management features with this version and look if your problem remain.

Thanks in advance

Gilles Caulier

Problem is fixed with new 7.0.0-beta1 through this long story from this bug

https://bugs.kde.org/show_bug.cgi?id=399923

You can test digiKam 7.0.0-beta1 with bundle available here:

https://download.kde.org/unstable/digikam/

Don't hesitate to give us a fresh feedback about his entry.

Thanks in advance

Gilles Caulier