| Summary: | Digikam uses all memory with thumbnails | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Frank Hommes <freanki> |
| Component: | Thumbs-Image | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | aspotashev, caulier.gilles |
| Priority: | NOR | ||
| Version: | 1.3.0 | ||
| Target Milestone: | --- | ||
| Platform: | Unlisted Binaries | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 1.4.0 | |
| Sentry Crash Report: | |||
|
Description
Frank Hommes
2010-07-05 21:38:10 UTC
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 |