Version: 0.9.5-beta2 (using KDE 3.5.10) Compiler: gcc 4.3.2 amd64 OS: Linux Installed from: Ubuntu Packages digikam crashes when I sequencely edit several (~10) huge images (16 bit tiffs). Console output: QFile::open: No file name specified lcms: Error #12288; Read from memory error. Got 0 bytes, block should be of 128 bytes lcms: Error #12288; Corrupted memory profile QComboBox::setCurrentItem: (unnamed) Index 3 out of range JPEG image preview size: (770 x 1024) pixels - 75105 bytes Exif orientation tag set to: 1 Cannot save metadata using Exiv2 (Error #31: Writing to %2 images is not supported) Exif Orientation: 1 QFile::open: No file name specified lcms: Error #12288; Read from memory error. Got 0 bytes, block should be of 128 bytes lcms: Error #12288; Corrupted memory profile terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Aborted (core dumped) Also I have huge enough core.bz2=846M, not sure how to send it.
You can get core from here: http://petrel.telecom.mipt.ru/~olleg/digikam.core.bz2
In digikam 0.10.0 the same.
Can you provide an example image somewhere? Can you remember the filters you were using? There is another bugreport describing similar problems, but at least valgrind doesn't show memory leaks.
Version 1.0.0.beta6, bug is here still. How to reproduce. I have several png images 14 Mpx, 16 bpp, 62 MiB. When I open one of them in Editor and try to push button Next/Prev, the memory slightly temporaly increases on loading new image (on 110 MiB), but quickly releases back and in result memory is stable. It's ok. But if I try to edit image first (crop, resize, 16bpp->8bpp,save) memory consumption is decreased. But on load next image (button next) memory permanently grows up on 110 MiB, for instance from 1876 MiB to 1991 MiB. After this if I press Prev button without editing to the edited image, memory decreased to 1876 MiB back.
digiKam 1.0.0 is out since few days... http://www.digikam.org/drupal/node/491 Please try with this version coming with more than 400 bug-fixes. Thanks in advance Gilles Caulier
I can confirm this problem still exists in 1.0.0 release. The issue is to do with loading new images in the Image Editor without closing the Image Editor itself. I observe: 1) If I open a sequence of Canon Raw images from an Album, each time saving to a JPEG2000 file and closing the Image Editor window between each, then memory usage remains constant. I can carry on doing this for as long as I like. 2) If I open a sequence of Canon Raw images from an Album, each time saving to a JPEG2000 file, but not closing anything - just switch back to the album, select a new image and press F4 to load the images into the Image Editor. Doing this the memory usage rises inexorably, eventually consuming all the available physical memory (I don't have the patience to try and exaugst 12GB of swap space). This took about 30 images (12 Mpixel) to use up the 4GB of physical memory I have installed. Closing the image editor doesn't free this memory up - I can close the Image Editor and go back to the Album view, but the memory usage remains high. I have to close Digikam in order to (slowly) free the memory. My suspicion is that the problem is with what happens to the modified image buffer when one image replaces another in the Image Editor - either the actual buffer, or the undo history or something. For reference my sequence of effects is: 1) White balance 2) Sharpen 3) 16bit->8bit Optionally add free rotation and crop / aspect ratio crop to those, but I don't think these make any difference to the issue. If you want exact steps I can almost certainly generate some for you.
Richard, If you use another file format than JPEG2000, as PNG or TIFF or JPEG, can you reproduce memory leak ? Gilles Caulier
Sadly, the same symptoms can be produced with PNG files (compression setting 1, for what it's worth). For all of the images I tested I did the same sequence of operations: 1) Open Raw 2) White Balance 3) Sharpen 4) Aspect Ratio crop 5) Change Colour Depth to 8-bit 6) Save to PNG file (in a different album) When I started digikam I ran free -m and it looked like this: total used free shared buffers cached Mem: 3962 2218 1743 0 97 1736 -/+ buffers/cache: 385 3577 Swap: 11719 2 11716 After processing 5 images it looked like this: total used free shared buffers cached Mem: 3962 3483 478 0 98 2321 -/+ buffers/cache: 1063 2898 Swap: 11719 2 11716 which might not matter (there is still free memory, and the cache has gone up)), except that when I look at the process memory allocations by running ps aux I get %CPU %MEM VSZ RSS TIME COMMAND 13.2 21.0 2062528 852468 2:35 digikam 0.0 0.1 148744 8040 0:00 kdeinit4: 0.0 0.1 147644 6908 0:00 kdeinit4: 0.0 0.6 319152 24860 0:00 kdeinit4: 0.0 0.6 320472 25604 0:00 kdeinit4: 0.0 0.7 322356 28464 0:00 kdeinit4: 0.0 0.0 7672 788 0:00 grep so the main digikam process has slightly under 2GB of memory allocated. If I carry on and do another 5 images in the same way, we get even more allocated memory %CPU %MEM VSZ RSS TIME COMMAND 18.3 35.5 2641972 1443136 6:06 digikam 0.0 0.1 148744 8040 0:00 kdeinit4: 0.0 0.1 147644 6912 0:00 kdeinit4: 0.0 0.6 320936 25060 0:00 kdeinit4: 0.0 0.6 319248 24544 0:00 kdeinit4: 0.0 0.6 323008 26828 0:00 kdeinit4: 0.0 0.0 7672 804 0:00 grep now 2.5GB allocated. Closing down the Image Editor window doesn't help must with that: %CPU %MEM VSZ RSS TIME COMMAND 17.7 34.5 2599488 1400652 6:07 digikam 0.0 0.1 148744 8040 0:00 kdeinit4: 0.0 0.1 147644 6912 0:00 kdeinit4: 0.0 0.6 320936 25060 0:00 kdeinit4: 0.0 0.6 319248 24544 0:00 kdeinit4: 0.0 0.6 323008 26828 0:00 kdeinit4: 0.0 0.0 7672 808 0:00 grep to get the memory back I have to quit digikam, as before. I'll try another output format and no processing, see what that does to the results.
This time, just save the loaded image straight to PNG, no processing: start off %CPU %MEM VSZ RSS TIME COMMAND 22.7 4.1 1299936 169872 0:02 digikam after 5 images: %CPU %MEM VSZ RSS TIME COMMAND 48.6 7.5 1448720 307948 1:29 digikam after 10 %CPU %MEM VSZ RSS TIME COMMAND 47.6 8.5 1480828 346508 2:57 digikam That's still going up, but it's very modest compared to the previous run. So it seems that something more than just opening and closing images has to be going on. Try again, this time open each image (same images), change colour depth to 8bit, then save as PNG in same folder. At start-up of digikam: %CPU %MEM VSZ RSS TIME COMMAND 37.4 4.1 1390416 168484 0:02 digikam After 5 images: %CPU %MEM VSZ RSS TIME COMMAND 41.1 6.2 1481260 252748 1:21 digikam After 10 images: %CPU %MEM VSZ RSS TIME COMMAND 39.9 6.4 1486236 259832 2:40 digikam Looks like that's OK as well then. So this bug only shows up if you do some amount of editing on the image it seems. Will have to try doing more in the way of processing to work out when the memory leaks start happening. Idly wander if the preview images from the effects aren't being freed like they should be? Or undo history stack? Colour depth conversion appears in the Undo history but doesn't have a preview image because there are no parameters.
You could further investigate this using valgrind's tool "massif". Ensure you have debug info installed for digikam. Then run valgrind --tool=massif digikam which will be a good deal slower than usual. Try to provoke the problem (if it's taking really long, just do one or two images), and close the program normally. In the current directory you will then find a file massif.out.<PID> which you can post here.
Created attachment 39726 [details] Output of valigrind in massig mode (for SVN r1072278 up to crash) I tried this using a build from latest SVN (r1072278) because that has debug symbols in it. I ran digikam from the top of the build tree (following the instructions on http://www.digikam.org/drupal/download/KDE4, thanks!) as valgrind --tool=massif ./digikam/digikam/digikam but although I got the image editor open, as soon as I tried to open the White Balance tool the whole lot crashed. I got two files, the one attached and an identical file with the same mtime called massif.out.12961. I realise this isn't what you wanted, so I'm backing up SVN to find a revision that doesn't crash on white balance under Massif.
Created attachment 39727 [details] Output of valigrind in massif mode (for SVN r1067737) This is a complete massif run over two images. Same set of actions as in comment #8, except I went back to JPEG2000 images. For this I used a check-out of SVN r1067737 (post 1.0.0 release) because White Balance doesn't crash there. I've since run through a longer batch of images not under Valgrind using the same binary, to try and confirm that it has the same memory leakage issues as we have been testing in 1.0.0. Unfortunately after 8 images the results were inconclusive - some growth, but not enough to be certain that it's leaking as badly as before: %CPU %MEM VSZ RSS TIME COMMAND 16.0 4.1 1333512 169108 0:02 ./digikam/digikam/digikam to: %CPU %MEM VSZ RSS TIME COMMAND 23.4 24.1 2142684 981528 5:47 ./digikam/digikam/digikam I need to do some more testing, unfortunately this will have to be parked until Friday due to work, but I think I'll try building SVN HEAD at that point and see if I can reproduce the original bug in that before we invest any more time in this issue.
Analyzing the last snapshot of your second massif log, about 60% of memory was allocated in libjasper, used for loading or saving JPEG2000 files. There is 20% image data allocated from ImageRegionWidget, which is used by some image plugins, and 4% image data from depth conversion. I also had the white balance crash. You need to recompile and "make install" to replace the old white balance binary. Is the memory usage you observe closely associated with loading or saving JPEG2000 images?
Nope, maybe JPEG2000 is another bug. :) I doesn't use it at all. In my case there was only changing size and color depth of PNG.
digiKam and Kipi-plugins 1.2.0 are out. Please check if crash is still valid there. Thanks in advance Gilles Caulier
I'm afraid I think it still is - now that I've got a build that doesn't seg fault every few minutes, after 9 images (Canon raw to JPEG2000): %CPU %MEM VSZ RSS TIME COMMAND 18.5 58.2 3498228 2362708 10:04 digikam After 13 images the machine is starting to grind %CPU %MEM VSZ RSS TIME COMMAND 20.3 75.7 4466928 3075216 14:00 digikam
Is this isolated to JPEG2000 images? I have recently (May 28) fixed a memory leak affecting all image plugins. Is this fix included in your version?
Probably not. I was hoping to test this, but as Digikam 1.3.0 depends on unreleased library code from kde 4.5, I can't. And no, I'm not going to install SVN versions of kdegraphics on my system in order to test this, because I'd like to still have a working system. If there are some instructions on how to statically link digikam to the offending libraries, then fair enough, but depending on an unreleased version of a sytstem-wide shared library is a major pain.
Richard, Can you test using a recent digiKam version as 1.4.0... Gilles Caulier
Looked like fixed in Version 1.6.0 (rev.: 1187916).