Bug 350549 - massive memory usage when assigning a tag to a recognized face
Summary: massive memory usage when assigning a tag to a recognized face
Alias: None
Product: digikam
Classification: Applications
Component: Faces-Engine (show other bugs)
Version: 4.4.0
Platform: Mint (Debian based) Linux
: NOR major
Target Milestone: ---
Assignee: Digikam Developers
Depends on:
Reported: 2015-07-23 14:33 UTC by b-schaefer
Modified: 2019-12-23 06:17 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 7.0.0


Note You need to log in before you can comment on or make changes to this bug.
Description b-schaefer 2015-07-23 14:33:53 UTC
At first install I chose an option about writing Metadata directly to the pictures which increases interoperability. I can not find the option anywhere. (Maybe related)
Whenever I assign a tag to a picture where a face is recognized by digikam or where I "add the face" digikam takes up increasing amounts of memory rendering the whole system unresponsive. It is independent of whether I want to create a new tag or assign an existing one. Same thing happens with a new database (deleting the old one).
The first couple of times I assigned tags it all went well. Then sometimes when I double clicked a picture in the multi-preview mode I got a segmentation fault.
I am using LMDE 2 'Betsy'. 

Reproducible: Always

Steps to Reproduce:
1. something (don't know what)
2. tag a face
3. massive memory usage

Actual Results:  
whole system unresponsive

Expected Results:  
tag is stored in database and picture metadata and work can be continued

Even when i kill digikam after tagging the data is still stored in the database as well as in the picture.
Comment 1 caulier.gilles 2015-07-23 21:55:49 UTC

*** This bug has been marked as a duplicate of bug 338176 ***
Comment 2 Maik Qualmann 2017-12-17 19:49:34 UTC
Git commit 6a9fd9891a3ff341dc42fe36158cbf0101d513b6 by Maik Qualmann.
Committed on 17/12/2017 at 19:20.
Pushed by mqualmann into branch 'master'.

delete threads from memory when they are finished
Related: bug 375317, bug 375035, bug 321784, bug 325712, bug 328732, bug 330227, bug 331912, bug 344661, bug 345395, bug 381877, bug 338249, bug 329651, bug 329091, bug 387821, bug 381222

M  +2    -1    NEWS
M  +25   -0    libs/database/dbjobs/dbjobsmanager.cpp
M  +35   -0    libs/iojobs/iojobsmanager.cpp

Comment 3 caulier.gilles 2017-12-17 20:03:15 UTC
Following this commit:


... the approach to fix this problem is under way and new digiKam 5.8.0 pre-release bundles will be compiled tonight to lets a chance to end-users to give a feedback about this fix before the 5.8.0 official release planed before Christmas 2017.

The bundles will be available in 2 hours at this url:


Please do not waste time to test if this file is always valid for next 5.8.0.

Thanks in advance

Gilles Caulier
Comment 4 caulier.gilles 2019-12-23 06:17:19 UTC
Problem is fixed with new 7.0.0-beta1 through this long story from this bug


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


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

Thanks in advance

Gilles Caulier