| Summary: | First crashes when saving tiff file, then crashes when starting. | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Henrik Vedel <hamhenrik> |
| Component: | Metadata-Versioning | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | grave | CC: | caulier.gilles, metzpinguin |
| Priority: | NOR | ||
| Version: | 5.8.0 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 6.0.0 | |
| Sentry Crash Report: | |||
|
Description
Henrik Vedel
2018-02-16 19:15:28 UTC
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 |