https://bugs.kde.org/show_bug.cgi?id=390580
--- Comment #2 from Henrik Vedel <[email protected]> --- 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 -- You are receiving this mail because: You are watching all bug changes.
