Bug 321784 - Recreating fingerprints leaks memory
Summary: Recreating fingerprints leaks memory
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Database-Similarity (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-30 10:37 UTC by Christoph Feck
Modified: 2019-12-24 08:54 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 7.0.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Feck 2013-06-30 10:37:22 UTC
Steps to reproduce:
- start a fresh digikam (no database)
- add Album with 70,000 photos
- go to Fuzzy Searches
- when asked about creating fingerprints, click "OK"
- press Ctrl+Esc to watch memory usage of digikam

Actual results:
- process memory continuously grows about 1 MB per second

Expected results:
- process memory stays stable after some time

Right now, it only has created fingerprints for 3% of my collection, and already grew by about 100 MB. I expect that I either have to kill it later, or it crashes, because my 32 bit system cannot offer 3 GB memory to processes.
Comment 1 Christoph Feck 2013-06-30 10:54:44 UTC
Btw, I am using today's master.

digiKam version 3.3.0-beta3
Exiv2 can write to Jp2: Yes
Exiv2 can write to Jpeg: Yes
Exiv2 can write to Pgf: Yes
Exiv2 can write to Png: Yes
Exiv2 can write to Tiff: Yes
Exiv2 supports XMP metadata: Yes
LibCImg: 130
LibEigen: 3.1.3
LibExiv2: 0.23
LibJPEG: 80
LibJasper: 1.900.1
LibKDE: 4.10.90
LibKExiv2: 2.3.1
LibKGeoMap: 2.0.0
LibKdcraw: 2.3.1
LibLCMS: 2040
LibLensFun: 0.2.7-0
LibPGF: 6.12.24 - external shared library
LibPNG: 1.6.2
LibQt: 4.8.4
LibRaw: 0.15.2
LibTIFF: LIBTIFF, Version 4.0.3 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc.
Marble Widget: 0.15.80 (0.16 Beta 1)
Parallelized PGF codec: No
Parallelized demosaicing: No
RawSpeed codec support: No
Database backend: QSQLITE
Kipi-Plugins: 3.3.0-beta3
LibGphoto2: 2.5.2
LibKface: 3.0.0
LibKipi: 2.1.0
LibOpenCV: 2.4.5
Comment 2 Christoph Feck 2013-06-30 11:23:06 UTC
It stays constant after about using 350 MB, probably after some caches are filled up and start evicting.
Comment 3 Maik Qualmann 2017-12-17 19:21:31 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 325712, bug 328732, bug 330227, bug 331912, bug 344661, bug 345395, bug 350549, 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

https://commits.kde.org/digikam/6a9fd9891a3ff341dc42fe36158cbf0101d513b6
Comment 4 caulier.gilles 2017-12-17 20:01:09 UTC
Following this commit:

https://commits.kde.org/digikam/6a9fd9891a3ff341dc42fe36158cbf0101d513b6

... 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:

https://files.kde.org/digikam/

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

Thanks in advance

Gilles Caulier
Comment 5 caulier.gilles 2019-12-24 08:54:53 UTC
Not reproducible with 7.0.0-beta1