Summary: | Crash when deleting images while viewing them | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Michael G. Hansen <mike> |
Component: | Database-Models | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | ahuggel, andresbajotierra, caulier.gilles, marcel.wiesweg |
Priority: | NOR | ||
Version: | 1.0.0 | ||
Target Milestone: | --- | ||
Platform: | Debian testing | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 7.5.0 | |
Sentry Crash Report: |
Description
Michael G. Hansen
2009-06-18 11:08:29 UTC
Marcel, I think it crash because KDirWatch fire a signal differently now, especially when operation just started on HDD. With image editor, i can see KDirWatch event when image starting to be written using file save as. KExiv2 is called a lots of time until image is complete on disk. This is really weird. I think this report need to be fork to Kdelibs to revert last changes in KDirWatch. Andreas : Exiv2 crash because the file scanned is corrupted : it 's under removing from HDD... Anyway, Exiv2 must don't crash here... Gilles Caulier Marcel, Sound like this commit from KDirWatch is the problem: http://websvn.kde.org/?view=rev&revision=925654 Andreas, In digiKam, we use KDirWatch to look events from HDD, especially when new files are added or changed externally. In this case, we scan item and register metadata to database. http://api.kde.org/4.x-api/kdelibs-apidocs/kio/html/classKDirWatch.html Gilles Caulier This backtrace looks very similar to the first one in bug #196726 reported by Salvatore recently. I wonder why there are suddenly two similar crashes within days? The Exiv2 code that calls the libc function which fails never gave problems and hasn't changed in years. A simple fread() to read the first 2 bytes of a JPEG file crashes. I don't quite see what to do to avoid this. Andreas Yes, the behavior of KDirWatch changed drastically from KDE4.2.2 to KDE4.2.3 I think. For me it is no good practice to change such behavior in a stable release, but we have it now, we will have users running KDE4.2.4. There is a timer between a dirwatch signal and the triggered scan. But a writing operation can always be active on any file, even from outside digikam. I wonder if it is possible to test for this? The Exiv2 IO classes use basic C functions (and mmap, but not in this case), they don't know about KDirWatch et al. They rely on these C functions to return an error if something unforeseen happens. The title and part of the backtrace matches bug 194330. Thanks Thanks Dario. set as duplicates. Gilles Caulier *** This bug has been marked as a duplicate of bug 194330 *** Fixed with https://bugs.kde.org/show_bug.cgi?id=194330 |