Bug 246675

Summary: crash on startup/scanning folders
Product: [Applications] digikam Reporter: Andrew Ziem <ahz001>
Component: Metadata-EngineAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: crash CC: ahuggel, caulier.gilles, marian75014
Priority: NOR    
Version: 1.2.0   
Target Milestone: ---   
Platform: Fedora RPMs   
OS: Linux   
Latest Commit: Version Fixed In: 1.4.0
Attachments: stack trace

Description Andrew Ziem 2010-08-04 06:55:36 UTC
Created attachment 49799 [details]
stack trace

Version:           1.2.0 (using KDE 4.4.5) 
OS:                Linux

Every time I start Digikam 1.2.0 on Fedora 13 it crashes.  

Reproducible: Always

Steps to Reproduce:
1. Start Digikam
2. Do not abort folder scanning


Actual Results:  
It crashes

Expected Results:  
No crash

My session is GNOME.  I never used Digikam before.  If I cancel the scanning, it starts OK.
Comment 1 Andrew Ziem 2010-08-04 07:14:41 UTC
on terminal before crash


Warning: Directory NikonPreview, entry 0x0201: Data area exceeds data buffer, ignoring it.
Warning: Directory NikonPreview, entry 0x0201: Data offset entry value is empty, ignoring it.
Warning: Directory NikonPreview, entry 0x0201: Size and data offset entries have different number of components, ignoring them.
KCrash: Application 'digikam' crashing...
sock_file=/home/z/.kde/socket-a.z/kdeinit4__0
QSocketNotifier: Invalid socket 18 and type 'Read', disabling...
QSocketNotifier: Invalid socket 23 and type 'Read', disabling...
QSocketNotifier: Invalid socket 26 and type 'Read', disabling...
digikam: Fatal IO error: client killed
Comment 2 Johannes Wienke 2010-08-04 10:19:23 UTC
Please attach a backtrace to this report either from the crash assistant or through running digikam in gdb:
http://www.digikam.org/drupal/docs?q=contrib
Comment 3 Johannes Wienke 2010-08-04 10:21:38 UTC
Also enable full debugging for digikam in kdebugdialog and paste the last few lines of output before the crash.
Comment 4 Johannes Wienke 2010-08-04 10:23:27 UTC
Argh, forget about the backtrace. ;) Why are these attachments so invisible?

Thread 2 (Thread 0xb61bbb70 (LWP 18206)):
[KCrash Handler]
#6  Exiv2::ValueType<unsigned short>::toLong (this=0xb54bfe28, n=0) at value.hpp:1548
#7  0x05e87bf5 in Exiv2::Exifdatum::toLong (this=<value optimized out>, n=<value optimized out>) at exif.cpp:407
#8  0x042b7c47 in KExiv2Iface::KExiv2::getImageOrientation() const () from /usr/lib/libkexiv2.so.8
#9  0x072d2a01 in Digikam::DMetadata::getMetadataField (this=0xb61badac, field=Digikam::MetadataInfo::Orientation) at /usr/src/debug/digikam-1.2.0/libs/dmetadata/dmetadata.cpp:1163
#10 0x072d484f in Digikam::DMetadata::getMetadataFields (this=0xb61badac, fields=...) at /usr/src/debug/digikam-1.2.0/libs/dmetadata/dmetadata.cpp:1362
#11 0x06354099 in Digikam::ImageScanner::scanImageInformation (this=0xb61bada4) at /usr/src/debug/digikam-1.2.0/libs/database/imagescanner.cpp:275
#12 0x063581e8 in Digikam::ImageScanner::scanFile (this=0xb61bada4, mode=Digikam::ImageScanner::NewScan) at /usr/src/debug/digikam-1.2.0/libs/database/imagescanner.cpp:237
#13 0x063583fe in Digikam::ImageScanner::newFile (this=0xb61bada4, albumId=254) at /usr/src/debug/digikam-1.2.0/libs/database/imagescanner.cpp:101
#14 0x06308076 in Digikam::CollectionScanner::scanNewFile (this=0xb61bb230, info=..., albumId=254) at /usr/src/debug/digikam-1.2.0/libs/database/collectionscanner.cpp:756
#15 0x06309694 in Digikam::CollectionScanner::scanAlbum (this=0xb61bb230, location=..., album=...) at /usr/src/debug/digikam-1.2.0/libs/database/collectionscanner.cpp:665
#16 0x0630951a in Digikam::CollectionScanner::scanAlbum (this=0xb61bb230, location=..., album=...) at /usr/src/debug/digikam-1.2.0/libs/database/collectionscanner.cpp:683
#17 0x0630951a in Digikam::CollectionScanner::scanAlbum (this=0xb61bb230, location=..., album=...) at /usr/src/debug/digikam-1.2.0/libs/database/collectionscanner.cpp:683
#18 0x0630a339 in Digikam::CollectionScanner::scanAlbumRoot (this=0xb61bb230, location=...) at /usr/src/debug/digikam-1.2.0/libs/database/collectionscanner.cpp:479
#19 0x0630a66f in Digikam::CollectionScanner::completeScan (this=0xb61bb230) at /usr/src/debug/digikam-1.2.0/libs/database/collectionscanner.cpp:250
#20 0x082c145e in Digikam::ScanController::run (this=0x8795a08) at /usr/src/debug/digikam-1.2.0/digikam/scancontroller.cpp:541
#21 0x03f7574f in ?? () from /usr/lib/libQtCore.so.4
#22 0x00bfa919 in start_thread () from /lib/libpthread.so.0
#23 0x00b17cbe in clone () from /lib/libc.so.6

This is a crash in exiv2. Which version are you using? Please update to the most recent version if possible.
Comment 5 Andreas Huggel 2010-08-04 13:27:45 UTC
Is toLong() called on an empty value? That's the usual cause for this crash. The caller (libkexiv2) must ensure this does not happen by checking that the value has at least one element before calling toLong().

Andreas
Comment 6 Andrew Ziem 2010-08-04 15:24:58 UTC
My version which is installed now

$ rpm -qa| grep -i exiv
exiv2-libs-0.19-1.fc13.i686
exiv2-debuginfo-0.19-1.fc13.i686

If I try to upgrade to latest exiv2 0.20 from Fedora 14, it looks like I would need to rebuild several packages

$ sudo rpm -Uvh exiv2-debuginfo-0.20-1.fc14.i686.rpm exiv2-libs-0.20-1.fc14.i686.rpm exiv2-0.20-1.fc14.i686.rpm 
error: Failed dependencies:
        libexiv2.so.6 is needed by (installed) gpscorrelate-1.6.0-6.fc13.i686
        libexiv2.so.6 is needed by (installed) kdebase-runtime-libs-4.4.5-1.fc13.i686
        libexiv2.so.6 is needed by (installed) strigi-libs-0.7.2-5.fc13.i686
        libexiv2.so.6 is needed by (installed) gthumb-2.11.5-1.fc13.i686
        libexiv2.so.6 is needed by (installed) kdegraphics-libs-7:4.4.5-2.fc13.i686
        libexiv2.so.6 is needed by (installed) hugin-base-2010.0.0-1.fc13.i686
Comment 7 Andrew Ziem 2010-08-10 06:04:56 UTC
Same symptoms when I tested in Ubuntu 10.04 with Digikam 1.2.0 and libexif 0.6.19 (in VirtualBox virtual machine with sshfs filesystem).  I think the crash happens on a certain image I took in the last year, but I am not sure which.
Comment 8 Johannes Wienke 2010-08-10 09:43:50 UTC
*** Bug 240957 has been marked as a duplicate of this bug. ***
Comment 9 Johannes Wienke 2010-08-10 09:44:15 UTC
*** Bug 247100 has been marked as a duplicate of this bug. ***
Comment 10 Johannes Wienke 2010-08-10 09:45:50 UTC
Which version of libkeiv are you using?
Comment 11 Johannes Wienke 2010-08-10 09:49:38 UTC
it should be "libkexiv".
Comment 12 Andrew Ziem 2010-08-10 18:33:35 UTC
$ rpm -q libkexiv2 exiv2{,-libs}
package libkexiv2 is not installed
exiv2-0.19-1.fc13.i686
exiv2-libs-0.19-1.fc13.i686

According to [1] the package libkexiv2 last existed in Fedora 9 (and I use Fedora 13).  There is now a package exiv2 [2].  Maybe it was renamed.

[1] https://admin.fedoraproject.org/pkgdb/acls/name/libkexiv2
[2] https://admin.fedoraproject.org/pkgdb/acls/name/exiv2

I tried to get exiv2 (command line tool) to crash with the following command, but I don't see a crash in the log

find ~/Pictures/2010 -iname '*JPG' -exec exiv2 \{\} \; &> /tmp/exiv2.log
Comment 13 Andrew Ziem 2010-08-10 18:37:32 UTC
According to [1] the package libkexiv2 is "Obsoleted by kdegraphics-4.1.0"

http://cvs.fedoraproject.org/viewvc/rpms/libkexiv2/devel/

$ rpm -q kdegraphics-libs
kdegraphics-libs-4.4.5-2.fc13.i686

$ rpm -q kdegraphics-libs --dump | grep libkexiv2
/usr/lib/libkexiv2.so.8 18 1278289608 0000000000000000000000000000000000000000000000000000000000000000 0120777 root root 0 0 0 libkexiv2.so.8.0.0
/usr/lib/libkexiv2.so.8.0.0 547740 1278289609 f5336f2e5d2d1744536b90226f460e22b2346669bf2ff4b4164764127b39ab0c 0100755 root root 0 0 0 X
Comment 14 Johannes Wienke 2010-08-10 21:01:42 UTC
SVN commit 1161754 by jwienke:

check that there are elements before calling toLong

CCBUGS: 246675

 M  +1 -1      kexiv2exif.cpp  
 M  +8 -8      kexiv2image.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1161754
Comment 15 Johannes Wienke 2010-08-10 21:03:30 UTC
Andrew, if possible please check that this fixes your problem by compiling the trunk version of libkexiv and digikam.

Andreas, is this the right way to check this?
Comment 16 Andreas Huggel 2010-08-11 09:33:49 UTC
Yes, that's the kind of check that is required.

Judging from this fix, a possible workaround should be to remove images from the collection which have an Exif.Thumbnail.Orientation tag with an empty value (i.e., for which the exiv2 command line tool shows a 0 for the number of elements)

Andreas
Comment 17 Andreas Huggel 2010-08-11 09:34:24 UTC
Yes, that's the kind of check that is required.

Judging from this fix, a possible workaround should be to remove images from the collection which have an Exif.Thumbnail.Orientation tag with an empty value (i.e., for which the exiv2 command line tool shows a 0 for the number of elements) or set the value to something meaningful.

Andreas
Comment 18 Johannes Wienke 2010-08-11 09:57:05 UTC
I think this patch should be backported to the current stable and distributed versions. Anyone knows how to do this or whom to contact?