Summary: | Crash in Image Editor after editing multiple (100+) pictures | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Simon <simon.eu> |
Component: | Plugin-DImg-RAW | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | ahuggel, caulier.gilles, marcel.wiesweg |
Priority: | NOR | ||
Version: | 1.1.0 | ||
Target Milestone: | --- | ||
Platform: | Unlisted Binaries | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 1.3.0 |
Description
Simon
2010-01-04 21:49:06 UTC
On Tuesday 05 January 2010 07:49:09 Simon wrote: > What I was doing when the application crashed: > I've been editing lots of images with 12 MP. I got this crash while the NEF > importer was opening a .NEF file (not converting yet). Most of the images > edited were simple .JPG files, only the last few were .NEF. Simon, This maybe fixed with the new exiv2 (0.19) uploaded to Debian sid recently. I suspect this is a duplicate report to Bug 220322. http://packages.debian.org/exiv2 Could I ask you to try and access your .NEF file using exiv2 0.18.2 (squeeze) first and confirm the problem and then try and access your file using exiv2 0.19 (sid) to confirm the issue has been solved. If that is the case, then you can either await digikam being rebuilt against the new exiv2 libs in sid, or you can rebuild the package yourself. Thanks, Mark This bug is not an exiv2 issue. The relevant part of the crash is this: Thread 13 (Thread 0xa3b18b70 (LWP 3185)): [KCrash Handler] #6 0xb68d5535 in Digikam::RAWLoader::loadedFromDcraw (this=0xa3b17b18, data=..., width=4310, height=2868, rgbmax=65535, observer=0xe6b9a40) at /data/cworkspace/graphics/digikam/libs/dimg/loaders/rawloader.cpp:186 #7 0xb68d4fc7 in Digikam::RAWLoader::load (this=0xa3b17b18, filePath=..., observer=0xe6b9a40) at /data/cworkspace/graphics/digikam/libs/dimg/loaders/rawloader.cpp:106 #8 0xb68b3abd in Digikam::DImg::load (this=0xa3b18218, filePath=..., loadFlagsInt=31, observer=0xe6b9a40, rawDecodingSettings=...) at /data/cworkspace/graphics/digikam/libs/dimg/dimg.cpp:444 "Exiv2" will show up in the backtrace if the crash happens in libexiv2 (but not all backtraces which contain Exiv2 are crashes from libexiv2 :). Andreas Which libkdcraw version you use ? Gilles Caulier $ apt-cache policy libkdcraw7-dev libkdcraw7-dev: Installiert: 4:4.3.4-1 Kandidat: 4:4.3.4-1 Versions-Tabelle: *** 4:4.3.4-1 0 500 http://ftp.ch.debian.org unstable/main Packages 100 /var/lib/dpkg/status Go to Help/components Info dialog, and give me the contents... Gilles Caulier digiKam version 1.1.0 (rev.: 1066990) Exiv2 can write to Jp2: Yes Exiv2 can write to Jpeg: Yes Exiv2 can write to Pgf: No Exiv2 can write to Png: Yes Exiv2 can write to Tiff: Yes Exiv2 supports XMP metadata: Yes LibCImg: 130 LibExiv2: 0.18.2 LibJPEG: 62 LibJasper: 1.900.1 LibKDE: 4.3.4 (KDE 4.3.4) LibKExiv2: 0.6.0 LibKdcraw: 0.5.0 LibLCMS: 118 LibPGF: 6.09.44 LibPNG: 1.2.41 LibQt: 4.5.3 LibRaw: 0.7.2 LibTIFF: LIBTIFF, Version 3.9.2 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc. Marble widget: 0.8.1 Parallelized demosaicing: Yes LibGphoto2: 2.4.6 LibKipi: 0.4.0 Simon, can you provide one sample image causing the crash? No, sorry, I cannot. It wasn't caused by one specific image. After digikam crashed I restarted it and could edit it without any problems. digiKam 1.1. release will be done in few days. Please check if this entry still valid. Thanks in advance Gilles Caulier digiKam and Kipi-plugins 1.2.0 are out. Please check if crash is still valid there. Thanks in advance Gilles Caulier Just edited some images again, and ... digikam(2912)/digikam (core) Digikam::HistogramPainterPriv::scaleToPixmapHeight: Scaling value < 0: 0 . Falling back to 1.0 digikam(2912)/digikam (core) Digikam::HistogramPainterPriv::scaleToPixmapHeight: Scaling value < 0: 0 . Falling back to 1.0 digikam(2912)/digikam (core) Digikam::EditorToolThreaded::slotFilterFinished: Final "Gradation" completed... ./env_svn.sh: Zeile 11: 2912 Getötet $@ simon@lapL:/data/cworkspace/digikam-trunk$ QSqlDatabasePrivate::removeDatabase: connection 'digikamDatabase-38373008' is still in use, all queries will cease to work. QSocketNotifier: Invalid socket 11 and type 'Read', disabling... QSqlDatabasePrivate::removeDatabase: connection 'digikamDatabase-38373008' is still in use, all queries will cease to work. QSocketNotifier: Invalid socket 12 and type 'Read', disabling... I've disabled the swap partition. So that may be the reason for digikam having been killed by the kernel. Digikam not started: $ free total used free shared buffers cached Mem: 2060704 687484 1373220 0 20804 105364 Anything I could do helping to locate the bug? valgrind? Simon Quite reproducible. Just with 25 images à 12 MP. I usually closed the image editor after each edit, and the free RAM kept on decreasing. Little memory leak? simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1583704 477000 0 28104 256276 -/+ buffers/cache: 1299324 761380 Swap: 0 0 0 simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1687272 373432 0 30264 271440 -/+ buffers/cache: 1385568 675136 Swap: 0 0 0 simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1644952 415752 0 23132 235020 -/+ buffers/cache: 1386800 673904 Swap: 0 0 0 simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1714768 345936 0 17536 180772 -/+ buffers/cache: 1516460 544244 Swap: 0 0 0 simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1904368 156336 0 2720 106172 -/+ buffers/cache: 1795476 265228 Swap: 0 0 0 simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1904660 156044 0 2720 106260 -/+ buffers/cache: 1795680 265024 Swap: 0 0 0 (crash) Okay, here is how to reproduce it (at least on my machine with deactivated swap; with activated swap it might take a little longer, so better use swapoff before trying to reproduce :) ): 1 In Image View: F4, Shift-Ctrl-M, Ctrl-W, Page Down. (Edit, Curves dialog, close editor, next image.) (Curve might have to be different from default, i.e. cause some effect.) 2 Repeat until free ram does not decrease anymore (here some allocated RAM seems to be freed) 3 As soon as RAM no longer decreases: Apply Curves in Editor, Undo, or whatever. -> Crash. simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1148856 911848 0 30308 263028 -/+ buffers/cache: 855520 1205184 Swap: 0 0 0 simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1181752 878952 0 30332 276776 -/+ buffers/cache: 874644 1186060 Swap: 0 0 0 simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1389504 671200 0 30756 302356 -/+ buffers/cache: 1056392 1004312 Swap: 0 0 0 simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1672024 388680 0 31132 482556 -/+ buffers/cache: 1158336 902368 Swap: 0 0 0 simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1711668 349036 0 31148 520744 -/+ buffers/cache: 1159776 900928 Swap: 0 0 0 simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1712368 348336 0 31296 520820 -/+ buffers/cache: 1160252 900452 Swap: 0 0 0 simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1712392 348312 0 31304 520820 -/+ buffers/cache: 1160268 900436 Swap: 0 0 0 simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1712436 348268 0 31312 520832 -/+ buffers/cache: 1160292 900412 Swap: 0 0 0 simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1638972 421732 0 31692 324924 -/+ buffers/cache: 1282356 778348 Swap: 0 0 0 simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1679480 381224 0 31828 330996 -/+ buffers/cache: 1316656 744048 Swap: 0 0 0 simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1783032 277672 0 31860 331344 -/+ buffers/cache: 1419828 640876 Swap: 0 0 0 simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1827000 233704 0 31868 331860 -/+ buffers/cache: 1463272 597432 Swap: 0 0 0 simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1867372 193332 0 31884 332504 -/+ buffers/cache: 1502984 557720 Swap: 0 0 0 simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1923464 137240 0 31900 333104 -/+ buffers/cache: 1558460 502244 Swap: 0 0 0 simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1949260 111444 0 31440 312536 -/+ buffers/cache: 1605284 455420 Swap: 0 0 0 simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1898116 162588 0 29780 268728 -/+ buffers/cache: 1599608 461096 Swap: 0 0 0 (no longer decreasing from here on) simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1949820 110884 0 19272 240748 -/+ buffers/cache: 1689800 370904 Swap: 0 0 0 simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1947888 112816 0 15736 204136 -/+ buffers/cache: 1728016 332688 Swap: 0 0 0 simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1952064 108640 0 14508 165056 -/+ buffers/cache: 1772500 288204 Swap: 0 0 0 simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1960940 99764 0 1564 133340 -/+ buffers/cache: 1826036 234668 Swap: 0 0 0 simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 1951920 108784 0 1364 87720 -/+ buffers/cache: 1862836 197868 Swap: 0 0 0 (pressed «Apply» in Curves) (crash) simon@lapL:~$ free total used free shared buffers cached Mem: 2060704 647652 1413052 0 1420 56024 -/+ buffers/cache: 590208 1470496 Swap: 0 0 0 valgrind --leak-check=full digikam with the leak report given when shutting down (can be long) and/or valgrind --tool=massif digikam with a massif.out.<pid> file created. Both make digikam very slow, though. Only try a few iterations. The leak-check log is here: http://granjow.net/uploads/bugs/digikam-valgrind-bug-221281.log What I did is * Start digikam * Click a different folder * Click on an image to display it * F4 (Editor) * Shift-Ctrl-M (Curves) * Ctrl-W * Alt-F4 Massif output: http://granjow.net/uploads/bugs/digikam-bug221281-massif.out.3344 http://granjow.net/uploads/bugs/digikam-bug221281-massif.out.3418 SVN commit 1131569 by mwiesweg: No editor tool (one exception) cared to delete the preview widget and the settings widget. Usually, the preview widget hold a copy of the image data, which explains a significant memory leak each time a new tool is opened. Delete the two pointers in EditorTool to fix all current tools. CCBUG: 221281 M +0 -3 imageplugins/color/bwsepiatool.cpp M +3 -0 utilities/imageeditor/editor/editortool.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1131569 Thanks Simon. After thorough valgrinding, I have identified a major memory leak, see commit. I assume this bug is fixed, and will close it unless you still have problems. Two off-topic remarks: - Massif visualizer by Milian Wolff (http://milianw.de/blog/massif-visualizer-ready-for-testers-and-feedback) is extremely helpful for reading Massif output. Forget ms_print. - keeping all ICC profiles open for fast access is a memory hog (though of constant size). Here, it's 42MB of memory with a collection of 50 profiles. Needs to be intelligently improved in the future. Cool, seems much better now! (Couldn't make the memory go constantly down anymore.) Thank you! |