Created attachment 131111 [details] gdb log and backtrace SUMMARY STEPS TO REPRODUCE 1. run digikam-7.0.0-x86-64.appimage debug (downloaded August 12th 2020) 2. start face detection, skipping already processed files 3. observe some (low single digit) percentage of the progressbar advancing OBSERVED RESULT Crash due to double-free (see gdb excerpt attached). EXPECTED RESULT DigiKam should finish face detection without crashing. SOFTWARE/OS VERSIONS Windows: - macOS: - Linux/KDE Plasma: Ubuntu 18.04.5 LTS KDE Plasma Version: - KDE Frameworks Version: - Qt Version: the one bundled in the appimage (Qt5.14.2 according to lib in image?) ADDITIONAL INFORMATION
Are you on Ubuntu with an Intel processor? Please use the built-in GDB in the AppImage with the "debug" option when starting the AppImage for a backtrace. Maik
I'm on AMD (Phenom 1090T 6 core). Yes, I did produce that backtrace with the appimage internal debugging (using "debug" to run it).
Maik, Look the very similar backtrace from bug #425702... Exiv2 exception ? Gilles
The ticket looks similar, because I created them both in short succession =;-). But this one is a double free in a variant, the other one a metadata sigsev. Also the code segment locations in libdigikamcore.so.7.0.0 are quite far apart. So I think these are two distinct bugs.
Do you guys store symbol information for your release builds by any chance? Sorry, I never worked with the KDE code base before...
*** Bug 425702 has been marked as a duplicate of this bug. ***
@Gilles, no it is related to the private DImg container. We see this problem mostly on Ubuntu. I have never been able to reproduce this problem. I'm guessing that some kernel process is killing the private DImg container. There is no other explanation for crashes in the QMap for the attributes or the metadata container. Maik
Debug symbols are stored in large size bundles named with "-debug" suffix : https://files.kde.org/digikam/ This repository is the weekly build provided for testing last change in git repository. All is explained here: http://www-ftp.lip6.fr/pub/X11/kde-applicationdata/digikam/README Note: the same rule is used for official releases of course. Gilles Caulier
Cool, thank you! I'll try to reproduce some crashes with the debug bundle.
Just as additional information: I use 2.8 out of 8GB RAM, so I don't think this is due to memory pressure.
*** Bug 425703 has been marked as a duplicate of this bug. ***
Created attachment 131125 [details] Memory usage while scanning for faces No it looks like I _do_ have a problem with exhausted memory. My 8GB were eaten up completely while waiting for the debug build to crash. Is there anything I could do to prevent that?
I never reproduce this kind of memory leak on my computers. The problem is know since a very long time, but, without a way to reproduce, we cannot fix it. Gilles
Created attachment 131128 [details] gdb backtrace from debug bundle Ok, it ain't much, but it's honest work. Caught a crash with the debug bundle and memory was steady at 2.5GB, so no out of memory condition with this one. The first two stack frames had no locals, so I printed the first frame that did, hope it is not totally useless...
Fixed with bug 426175. Maik