Bug 425698

Summary: DigiKam face detection crash under Linux
Product: [Applications] digikam Reporter: kamu <kamu>
Component: Faces-DetectionAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: crash CC: caulier.gilles, kamu, metzpinguin
Priority: NOR    
Version: 7.0.0   
Target Milestone: ---   
Platform: Appimage   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=425702
Latest Commit: Version Fixed In: 7.2.0
Sentry Crash Report:
Attachments: gdb log and backtrace
Memory usage while scanning for faces
gdb backtrace from debug bundle

Description kamu 2020-08-23 08:08:05 UTC
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
Comment 1 Maik Qualmann 2020-08-23 08:51:54 UTC
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
Comment 2 kamu 2020-08-23 09:03:27 UTC
I'm on AMD (Phenom 1090T 6 core).

Yes, I did produce that backtrace with the appimage internal debugging (using "debug" to run it).
Comment 3 caulier.gilles 2020-08-23 09:10:45 UTC
Maik, 

Look the very similar backtrace from bug #425702...

Exiv2 exception ?

Gilles
Comment 4 kamu 2020-08-23 09:25:43 UTC
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.
Comment 5 kamu 2020-08-23 09:26:51 UTC
Do you guys store symbol information for your release builds by any chance?  Sorry, I never worked with the KDE code base before...
Comment 6 Maik Qualmann 2020-08-23 09:58:17 UTC
*** Bug 425702 has been marked as a duplicate of this bug. ***
Comment 7 Maik Qualmann 2020-08-23 10:03:04 UTC
@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
Comment 8 caulier.gilles 2020-08-23 10:05:20 UTC
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
Comment 9 kamu 2020-08-23 10:26:28 UTC
Cool, thank you!  I'll try to reproduce some crashes with the debug bundle.
Comment 10 kamu 2020-08-23 10:32:20 UTC
Just as additional information: I use 2.8 out of 8GB RAM, so I don't think this is due to memory pressure.
Comment 11 Maik Qualmann 2020-08-23 10:33:27 UTC
*** Bug 425703 has been marked as a duplicate of this bug. ***
Comment 12 kamu 2020-08-23 12:45:57 UTC
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?
Comment 13 caulier.gilles 2020-08-23 12:59:18 UTC
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
Comment 14 kamu 2020-08-23 14:53:07 UTC
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...
Comment 15 Maik Qualmann 2020-10-03 19:43:02 UTC
Fixed with bug 426175.

Maik