Version: 1.3.0 (using KDE 4.4.4) OS: Linux When I start Digikam it uses 200 MB of my memory. After some work it is over 400 mb. But I experienced some (nearly) crashes of my system with my harddrive running and running, the system hardly reacting anymore. Always while Digikam running. I found out that I let digikam show a tag with more than 10.000 pictures when this happens. I could reproduces this while surfing through my albums and the memory increasing all the time. I'm using Digikam 1.3 precompiled as written on http://www.digikam.org/drupal/node/528 but I think I was having that bug before too. Reproducible: Always Steps to Reproduce: Open a big album and watch your memory getting full. Watch some more until your memory is full and your computer gets reaaaaally slow :) Actual Results: Only a CTRL + ALT + DEL brings your system back... Expected Results: It should only use a specific amount of memory. Not everything it gets ;)
Run digiKam through valgrind to check where memory is lost (not reproducible here)... http://lxr.kde.org/source/extragear/graphics/digikam/HACKING#241 Gilles Caulier
I guess its not really a memory leak. When I choose a specific tag with more than 10.000 pictures it tries to load ALL of the thumbnails into memory. I just stopped the try out with valgrind when it used 2560476K of my memory. It seems to be a bug in the design that only occurs with big collections.
I can see a relevant problem in a log produces by "massif". The QImage data produced by the ThumbnailCreator is leaked. Unfortunately, massif of course does not tell me why it is leaked.
I believe I have narrowed down the problem to the storage happening between ThumbnailLoadThread::thumbnailLoaded and ThumbnailLoadThread::slotThumbnailsAvailable. When I replace that mechanism with direct signals, the leak is gone; but that's not an option, it blocking the event queue. In fact it's easy to check if there's a problem or not, just run digikam under massif opening an album with a few hundred or thousand images. If there's no leak, massif-visualizer shows a plateau at about 130MB. With the leak, it's linearly increasing. But currently I'm too blind to see the problem in the code.
SVN commit 1156220 by mwiesweg: Fix giant memory leak: For pixmap generation, results are stored in a list and harvested in the main thread, in a slot called by an interthread signal. As an optimization, for the thumbnail pregeneration thread, pixmap creation was switched off. Now these two facts interacted: Switching off pixmap creation was implemented by disconnecting the inter-thread signal, and all the thumbnail QImages were never harvested until application shutdown. BUG: 243692 M +9 -7 thumbnailloadthread.cpp M +1 -0 thumbnailloadthread.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1156220