I have found bug #314260 which described the problem: a directory contained a dozen large (20+MB) TIFs (generated by hugin btw) and it crashed digikam at startup. It was a bitch to figure out the problem since neither console nor debug contained the exact filenames (nor hashes nor anything useful), so first I thought it's about the pretty large thumbnails.db. Later it turned out that digikam crashed by scanning or displaying a subdirectory so I clicked them one-by-one (hadda be fast, like an action game) until the crasher was found. digikam(5561)/digikam (core): Cannot allocate buffer of size 2408382400 was one of the messages which probably mean that digikam wanted to use some extreme amounts of memory to do whatever thumbnailing. I believe I'd prefer _not_ to see thumbnails instead of startup crashing so probably some pre-allocation checks are in high demand. Reproducible: Always Steps to Reproduce: 1. 30+ TIFs in 20+MB size thrown in the middle of a large image collection subdir tree 2. start digikam 3. crash in 5 seconds I used the Debian package, neither git nor debug version as I don't have right now the bandwidth to gather all the stuff to compile it.
Are you able to view them in Gwenview?
I use geeqie generally and it was able to show them. Never heard about gwen :) But honestly I was so angry that I've deleted the files on the spot, so if you relaly believe it's related to the specific content I can recreate them with hugin. (Technically life isn't that simple: the files have been there for 2 months now and they ought to be already indexed without a crash. I mean, yeah, digicam crashes all the time (it proceeds quit with a crash most of the time) so I cannot be sure which one was it but startup crash wasn't on the menu until now. I am puzzled why it didn't crash so far and why started now, I believe I haven't upgraded it for months now. Nor kde libs. I can accept this bug to be closed after this confession, since it's partly based on unexplainable mistery.)
Run digiKam into GDB as explained here : https://www.digikam.org/contrib And report the crash trace... Note : I use also Hugin to make big panorama (200/300Mb TIFF), and there is no crash here to render thumbnails, preview and load image in editor. Gilles Caulier
example of 241Mb TIFF panorama show in digiKam : https://www.flickr.com/photos/digikam/15449257226/sizes/o/
(In reply to Gilles Caulier from comment #3) > Run digiKam into GDB as explained here : > > https://www.digikam.org/contrib > > And report the crash trace... Crash trace was pretty useless. It kept being pretty useless with exiv2 and kexiv2 debug symbols, and I couldn't conjure digikam debug symbols since, as I have mentioned, I don't have the means right now. (lib debug took 50 minutes to retrieve. go figure.) Basically it died in libkexiv2's thumbnail code, maybe it's the culprit, now that I started to think about it. > Note : I use also Hugin to make big panorama (200/300Mb TIFF), and there is > no crash here to render thumbnails, preview and load image in editor. I know, me too. But look what I found: the straces from yesterday. And they SIGSEGV'd on a different file (this bug was originally reproduced by not SIGSEGV but the mem allocation error, but they were oscillating a day before, probably depending on the selected albums of the collection). And now I went there and checked the file. Bang, sigsegv. Here's a trace which is _very_ similar to the one with the mem problem above: #0 0x00007fffedd396e5 in Exiv2::PreviewManager::getPreviewImage (this=0x7fff7803c390, properties=...) at preview.cpp:1157 #1 0x00007ffff5c12902 in KExiv2Iface::KExiv2Previews::data (this=0x7fff837fd710, index=0) at ../../libkexiv2/kexiv2previews.cpp:170 #2 0x00007ffff5c12a8b in KExiv2Iface::KExiv2Previews::image (this=<optimized out>, index=<optimized out>) at ../../libkexiv2/kexiv2previews.cpp:187 #3 0x00007ffff551807b in Digikam::ThumbnailCreator::createThumbnail(Digikam::ThumbnailInfo const&, QRect const&) const () from /usr/lib/digikam/libdigikamcore.so.4.3.0 #4 0x00007ffff551bcf9 in Digikam::ThumbnailCreator::load(QString const&, QRect const&, bool) const () from /usr/lib/digikam/libdigikamcore.so.4.3.0 #5 0x00007ffff551cbe2 in Digikam::ThumbnailCreator::load(QString const&) const () from /usr/lib/digikam/libdigikamcore.so.4.3.0 #6 0x00007ffff552b31f in ?? () from /usr/lib/digikam/libdigikamcore.so.4.3.0 #7 0x00007ffff5500b8e in Digikam::LoadSaveThread::run() () from /usr/lib/digikam/libdigikamcore.so.4.3.0 #8 0x00007ffff55352ee in Digikam::DynamicThread::DynamicThreadPriv::run() () from /usr/lib/digikam/libdigikamcore.so.4.3.0 #9 0x00007ffff1c528a4 in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #10 0x00007ffff1c5f3ff in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #11 0x00007fffecb370a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #12 0x00007ffff0e80c2d in clone () from /lib/x86_64-linux-gnu/libc.so.6 The image is pretty large so it's available here: http://vilya.grin.hu/t/digikrash01.png I believe this is the one but it's not easy to tell since digikam crashes when entering the collection.
*** This bug has been marked as a duplicate of bug 339144 ***
Fixed with bug #339144