After upgrading from Fedora 25 to 27, all software, digikam has become totally unstable. Crashes when saving tiff files, then crashes when starting. It is probably an exiv2 thing. I have have verified that the very things happens if I force to run on one cpu/thread. I have verified it is not due to a problem with the digikam database, as an artificial new user with almost no images have the same problems. It seems to be related to digikam having a problem saving information to tiff images, and then again re-reading it. For many years this worked perfectly.. I include an extract from gdb[New Thread 0x7ffe9a7fc700 (LWP 11015)] [New Thread 0x7ffe9bfff700 (LWP 11016)] [New Thread 0x7ffe997fa700 (LWP 11017)] [New Thread 0x7ffe98ff9700 (LWP 11018)] [New Thread 0x7ffe6bfff700 (LWP 11019)] [New Thread 0x7ffe6b7fe700 (LWP 11020)] Thread 26 "Thread (pooled)" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff1affd700 (LWP 10984)] 0x00007ffff56f3e1b in Exiv2::IptcData::printStructure(std::ostream&, unsigned char const*, unsigned long, unsigned int) () from /lib64/libexiv2.so.26 Missing separate debuginfos, use: dnf debuginfo-install OpenEXR-libs-2.2.0-10.fc27.x86_64 SuperLU-5.2.0-4.fc27.x86_64 alsa-lib-1.1.5-1.fc27.x86_64 armadillo-7.900.1-3.fc27.x86_64 arpack-3.5.0-4.fc27.x86_64 atlas-3.10.3-1.fc27.x86_64 blas-3.8.0-4.fc27.x86_64 bzip2-libs-1.0.6-24.fc27.x86_64 cfitsio-3.370-10.fc27.x86_64 cyrus-sasl-lib-2.1.26-34.fc27.x86_64 dbus-libs-1.12.0-1.fc27.x86_64 dbusmenu-qt5-0.9.3-0.15.20150604.fc27.x86_64 elfutils-libelf-0.170-1.fc27.x86_64 exiv2-libs-0.26-6.fc27.x
The same crash in Exiv2 has already been reported, so I close it as a duplicate. However, I could not reproduce the crash with the TIFF image here. Can you also provide a test image? Please also try the AppImage of www.digikam.org. Maik *** This bug has been marked as a duplicate of bug 387515 ***
I have now tested with AppImage, the behaviour is as with the fedora 27 version of digikam 5.8.0 reported originally. There are some important things to add: 1 The original digikam crash does (most times) not happen when saving the first image (I typically open a set, say 50m in the editor mode, and work on them and save them one by one), but about a handful images into the lot (not a fixed number) digikam 5.8.0 crashes when saving a tiff file. 2 Followingly digikam crashes when starting digikam - if trying to start from the same directory as that of the "bad" image. Digikam does not crash making another directory its start directory. But it does crash when moving to that directory. 3 After a number of restarts (not a fixed number) digikam will again function properly, being able to handle the "bad" image, both as regards going to that directory and editing the "bad" image. It is probably for the same reason digikam developers has so far not been able to reproduce the problem, when being handed a "bad" image. 4 To me the digikam crashes I experience look more and more like a problem of several processes orginating from digikam trying to obtain and/or write and/or use simultaneously, at a stage where the information about the image is different in the different realisations of it (the image file, the database, different parts of the pc-memory handling different threads). 5 It is very difficult to understand point 3, if it is not somehow related to a mismatch of information, not a single file saved improperly. There is no problem opening the "bad" image file with other image handling programmes. As far as I understand, upon start digikam first reads the database, then i goes to image directories and checks for changes to the images (which could have been performed by other image processing software since last run of digikam) and new images. Here is a clear sequence. Somehow the treading introduced to speedup digikam on a multicore machine might corrupt that at later stages of a digikam run. Notice that I have verified previously that crashes also happens when forcing single cpu running. But that doesn't force no threading. At least not in theory, I don't know about the digikam implementation of threading. 6 While the majority of my image processing takes place on vfat formatted discs (using both Linux and Windows software for the processing), I have now verified that the digikam 5.8.0 crashes also happen when working on tiff images on a linux native partition. 7 I have been trying hard to make digikam crash in a similar way when working on jpg files, so far without success. Is threaded handling of tiff writing/reading organised differently than for jpg files? Kind regards, Henrik
Is the source image a RAW file that you load in the Image Editor and edit and then save as TIFF image? If it is a RAW file, from which camera? Can you provide a test image? Maik
>7 I have been trying hard to make digikam crash in a similar way when >working on jpg files, so far without success. Is threaded handling of >tiff writing/reading organised differently than for jpg files? About this point, the high level multi-threaded code is the same between JPEG, TIFF, PNG. Only the low level code delegate to the right system library the way to read write data to target image, as libtiff, libjpeg, libpng, etc... Another very important point is the metadata : for all image format, all is delegate to libexiv2, which include a dedicated code for all image format. We have no control these low level libraries implementation. Exiv2 is a problematic part due to complexity of metadata to read write in all cases from a large amount of very similary image formats (RAW for ex), but different finaly. About Exiv2 and multicore support (multithread running on multicore), i writtten few mounth ago a unit test tool to scan my huge collection of test images, without to find a crash while reading and writing metadata in parallel. https://cgit.kde.org/digikam.git/tree/tests/dmetadata/metareaderthread.cpp Gilles Caulier
Not reproducible with 6.0.0