SUMMARY Digikam crashes when scanning for new items Backtrace from GDB: #0 0x00007f1a980ebd22 in raise () at /usr/lib/libc.so.6 #1 0x00007f1a76eeb3e0 in KCrash::defaultCrashHandler(int) () at /usr/lib/libKF5Crash.so.5 #2 0x00007f1a980ebda0 in <signal handler called> () at /usr/lib/libc.so.6 #3 0x00007f1a980ebd22 in raise () at /usr/lib/libc.so.6 #4 0x00007f1a980d5862 in abort () at /usr/lib/libc.so.6 #5 0x00007f1a7480f25f in pa_fdsem_post () at /usr/lib/pulseaudio/libpulsecommon-14.2.so #6 0x00007f1a7482f979 in pa_srbchannel_write () at /usr/lib/pulseaudio/libpulsecommon-14.2.so #7 0x00007f1a7482bac7 in () at /usr/lib/pulseaudio/libpulsecommon-14.2.so #8 0x00007f1a7482cac4 in () at /usr/lib/pulseaudio/libpulsecommon-14.2.so #9 0x00007f1a7482ced7 in () at /usr/lib/pulseaudio/libpulsecommon-14.2.so #10 0x00007f1a7482fa6a in () at /usr/lib/pulseaudio/libpulsecommon-14.2.so #11 0x00007f1a79d89c23 in pa_mainloop_dispatch () at /usr/lib/libpulse.so.0 #12 0x00007f1a79d8a291 in pa_mainloop_iterate () at /usr/lib/libpulse.so.0 #13 0x00007f1a79d8a331 in pa_mainloop_run () at /usr/lib/libpulse.so.0 #14 0x00007f1a79e3996e in () at /usr/lib/libopenal.so.1 #15 0x00007f1a9836b3c4 in std::execute_native_thread_routine(void*) (__p=0x55818a956cf0) at /build/gcc/src/gcc/libstdc++-v3/src/c++11/thread.cc:82 #16 0x00007f1a942f6259 in start_thread () at /usr/lib/libpthread.so.0 #17 0x00007f1a981ad5e3 in clone () at /usr/lib/libc.so.6 Output from digikam: ❯ digikam QtAV 1.13.0(Jul 11 2019, 03:26:54) Multimedia framework base on Qt and FFmpeg. Distributed under the terms of LGPLv2.1 or later. Shanghai, China Copyright (C) 2012-2019 Wang Bin (aka. Lucas Wang) wbsecg1@gmail.com Donate: http://qtav.org/donate.html Source: https://github.com/wang-bin/QtAV Home page: http://qtav.org [ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1) [ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1) kf.xmlgui: Unhandled container to remove : Digikam::DigikamApp KCrash: crashing... crashRecursionCounter = 2 KCrash: Application Name = digikam path = /usr/bin pid = 713506 KCrash: Arguments: /usr/bin/digikam KCrash: Attempting to start /usr/lib/drkonqi pa_write() failed while trying to wake up the mainloop: Bad file descriptor pa_write() failed while trying to wake up the mainloop: Bad file descriptor pa_write() failed while trying to wake up the mainloop: Bad file descriptor Invalid write to eventfd: Bad file descriptor Code should not be reached at ../pulseaudio/src/pulsecore/fdsem.c:199, function pa_fdsem_post(). Aborting. Unable to start Dr. Konqi Re-raising signal for core dump handling. [1] 713506 abort (core dumped) digikam STEPS TO REPRODUCE 1. Start digikam with fresh database (mysql internal). 2. Set new removeable collection (from external hdd) 3. Scans for new items for a minute 2. Crash OBSERVED RESULT Digikam crashes during scanning process EXPECTED RESULT Digikam should not crash SOFTWARE/OS VERSIONS Linux/KDE Plasma: Archlinux (available in About System) KDE Plasma Version: 5.22.3 KDE Frameworks Version: 5.84.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION Mariadb 10.6.3 (upgraded from 10.5) PulseAudio 14.2 Problems first encountered after updating mariadb.
Downgrading mariadb to 10.5.11 appears to resolve the issue.
Can you create a better GDB backtrace again, I can't see anything from digiKam in the current log. See here for a backtrace: https://www.digikam.org/contribute/ If downgrading MariaDB helps, it is a package problem with your distribution or a problem with a very recent version of MariaDB. Maik
It seems to be a bug in the current MariaDB package under Archlinux: https://bugs.archlinux.org/task/71582?project=1&string=mariadb Maik
You are probably right. I'll try the updated archlinux packages to see if resolves my issue. Thank you for looking into the issue.
I see in our mailing list that digiKam from git / master should now work with the internal database. Since we start a mariadb-upgrade if different database and server versions. OpenSUSE does this automatically for the system database, you may have to do this manually for your external database under Archlinux. The new MariaDB version is a major update and has internal changes. Maik
I close this bug as a duplicate of Bug 440296, since we already have a possible cause there. *** This bug has been marked as a duplicate of bug 440296 ***
Fixed with #440296