| Summary: | Access to a specific jpg photo crashed digikam | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | krienke |
| Component: | Metadata-Engine | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | ahuggel, caulier.gilles |
| Priority: | NOR | ||
| Version: | 0.9.0 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 0.9.0 | |
| Sentry Crash Report: | |||
Andreas, And another one crash... Gilles Finally one that looks comprehensible, at least the reading part. Yes, I can reproduce the problem with the exiv2 utility and the image provided, will look into this. Did you use any software other than digikam to edit the image? If not, how exactly did you edit it; can you re-create similarly corrupted images with digikam? -ahu. Am Montag, 6. November 2006 09:48 schrieb Andreas Huggel: > ------- Additional Comments From ahuggel gmx net 2006-11-06 09:48 ------- > Finally one that looks comprehensible, at least the reading part. > > Yes, I can reproduce the problem with the exiv2 utility and the image > provided, will look into this. > > Did you use any software other than digikam to edit the image? > If not, how exactly did you edit it; can you re-create similarly corrupted > images with digikam? > I used digikam to edit the jpg comment and digikamimageplugins to enhance contrast. Thats all I did. I have a lot of other photos I edited in the same way and there are no similar problems. I even have a copy of this photo with the comment already included on another host and this version does not cause a crash (the size in bytes of both is identical). And I am quite sure, that I did not change anything else for this photo since I copied it to the other host. But since I had quite a lot of digikam crashes (possibly the hyperthreading bug) when I worked on the photos of my holidays (of which dsc_3393.jpg is one) I guess that one of this crashes must have corrupted the photo in question. Unfortunately I am unable to reproduce this problem, but anyway digikam should not crash when trying to extract the metadata of such a jpg even if the data contained in it are corrupt. Rainer I'm agree with you krienke, but the crash come from the Exiv2 shared library, not digiKam core directly (no blame here Andreas (:=))).... In fact, an exception must be generated by Exiv2 to prevent crash. This exception will be get by digiKam (the source code is already done in this way... Gilles > digikam should not crash when trying to extract the metadata of such a
> jpg even if the data contained in it are corrupt.
Sure, I also agree. I'll fix exiv2 as mentioned above. But I'm more worried if there is another, bigger problem here, which leads to images with corrupted metadata.
-ahu.
Exiv2 svn rev. 943 implements a quick fix (not a real solution). An exception is thrown now. -ahu. krienke, please try to use current svn implementation of Exiv2 and recompile digiKam & co. Thanks in advance Note : take you sure to uninstall the old version of Exiv2 before to install new one. Gilles Gilles, This one is straightforward, it is not related to the other crashes: The metadata in the image provided by krienke is corrupted and exiv2 < rev 943 chokes on it. To test, take the image from the link provided in the bug report and try with exiv2 < rev 943 to reproduce it and >= rev 943 to confirm that it's gone. Andreas Am Montag, 6. November 2006 18:22 schrieb Gilles Caulier:
> please try to use current svn implementation of Exiv2 and recompile digiKam
> & co. Thanks in advance
With the new svn version of exiv2 from Andreas digikam does no longer crash
and I can also assign e.g. a comment to the jpg that caused the crash.
Rainer
krienke, Sound like this file is solved with Exiv2 0.12 release. I close this file now. Gilles Caulier |
Version: 0.9.0-svn (using KDE KDE 3.5.4) Installed from: SuSE RPMs Compiler: gcc 4.1.0 OS: Linux I have a photo that first worked fine with dikikam. I did some editing on it, probably added a jpg comment to it in digikam which is stored inside the jpg. Now when digikam sees this file it crashes. Other tools like gwenview can however display it. The debug info is: Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1240016160 (LWP 15201)] [KCrash handler] #5 Exiv2::getLong (buf=0x397900e8 <Address 0x397900e8 out of bounds>, byteOrder=Exiv2::bigEndian) at types.cpp:196 #6 0xb79639af in Exiv2::getRational ( buf=0x397900e8 <Address 0x397900e8 out of bounds>, byteOrder=Exiv2::bigEndian) at types.cpp:202 #7 0xb791df4c in Exiv2::ValueType<std::pair<int, int> >::read ( this=0x8160df8, buf=0x397900e8 <Address 0x397900e8 out of bounds>, len=1786389032, byteOrder=Exiv2::bigEndian) at value.hpp:1014 #8 0xb79164de in Exiv2::Exifdatum::setValue (this=0xbfe026c0, e=@0x818b234, byteOrder=Exiv2::bigEndian) at exif.cpp:193 #9 0xb79165c0 in Exifdatum (this=0xbfe026c0, e=@0x818b234, byteOrder=<value optimized out>) at exif.cpp:97 #10 0xb791bba4 in Exiv2::ExifData::add (this=0x813d8cc, begin= {_M_current = 0x8187950}, end={_M_current = 0x818fd50}, byteOrder=Exiv2::bigEndian) at exif.cpp:764 #11 0xb791c20e in Exiv2::ExifData::load (this=0x813d8cc, buf=0x817b3c8 "MM", len=11509) at exif.cpp:596 #12 0xb793001b in Exiv2::JpegBase::readMetadata (this=0x813d8c0) at jpgimage.cpp:301 #13 0xb7eb457b in Digikam::DMetaLoader::loadWithExiv2 () from /opt/kde3/lib/libdigikam.so.0 #14 0xb7eb50d4 in Digikam::JPEGMetaLoader::load () from /opt/kde3/lib/libdigikam.so.0 #15 0xb7e9aa33 in Digikam::DMetadata::load () from /opt/kde3/lib/libdigikam.so.0 #16 0xb7e9d420 in Digikam::DMetadata::DMetadata () from /opt/kde3/lib/libdigikam.so.0 #17 0xb7cf3b10 in Digikam::ScanLib::storeItemInDatabase () from /opt/kde3/lib/libdigikam.so.0 #18 0xb7cf5798 in Digikam::ScanLib::allFiles () from /opt/kde3/lib/libdigikam.so.0 #19 0xb7cf5fd9 in Digikam::ScanLib::findMissingItems () from /opt/kde3/lib/libdigikam.so.0 #20 0xb7cf696f in Digikam::ScanLib::startScan () from /opt/kde3/lib/libdigikam.so.0 #21 0xb7c932af in Digikam::AlbumManager::setLibraryPath () from /opt/kde3/lib/libdigikam.so.0 #22 0x0804a375 in main () The file can be read from http://www.uni-koblenz.de/~krienke/tmp/dsc_3393.jpg Thanks Rainer