Bug 182738

Crash appears in Exiv2 library. Which version you use ?

Please give use a better backtrace. Run digikam in GDB as explained here :

http://www.digikam.org/drupal/contrib

Gilles Caulier

> Crash appears in Exiv2 library. Which version you use ?

In my system I have this one (rpm connected to exiv2):

libexiv2_4 ver. 0.17.1
libexiv2_5 ver. 0.18
libkexiv2_7 ver. 4.2.0


> Please give use a better backtrace.

For now, I can't give better backtrace info.
GPRS internet connection so debug rpms are to heavy for me now one.

You have both Exiv2 version installed at the same time. This is an origin to crash (here i have reproduce this dysfunction recently between Exiv2 0.16 and 0.18)

You must remove Exiv2 0.17.1, let's only 0.18, and cleanup and recompile :

libkexiv2
kipi-plugins 
digiKam

Gilles Caulier

> You must remove Exiv2 0.17.1, let's only 0.18, and cleanup and recompile :

libexiv2_4 removed and still same crash. 

I install Digikam from binary rpm, so it should be accurately compiled with libexiv2_5.

I pick out different, clean folder and then import my photos to it. Digikam crash when I want to import .jpg, mayby some of them have broke EXIF and Digikam just crash.

(I import some "test" jpg and Digikam work fine)

Daniel,

Can you try to identify the/an image which causes this crash and attach it here or send it to me at ahuggel at gmx dot net?


Gilles,

What is digiKam doing here:

#23 0x4368e44e in Exiv2::ExifParser::encode () from /usr/lib/libexiv2.so.5 
#24 0x42173bfb in ?? () from /usr/lib/libkexiv2.so.7 
#25 0x421726eb in KExiv2Iface::KExiv2::getExif () from /usr/lib/libkexiv2.so.7 #26 0x446408ad in Digikam::ImageScanner::loadFromDisk () from /usr/lib/libdigikamdatabase.so.1 

"loadFromDisk()" and "getExif()" sound like read-only operations, but "Exiv2::ExifParser::encode()" is usually called during writing??


-ahu.

Andreas,

ImageScanner::loadFromDisk() is here:

http://lxr.kde.org/source/extragear/graphics/digikam/libs/database/imagescanner.cpp#594

m_img, is a image conatiner (image dat + metadata)

http://lxr.kde.org/source/extragear/graphics/digikam/libs/database/imagescanner.h#156

http://lxr.kde.org/source/extragear/graphics/digikam/libs/dimg/dimg.h

But here, m_img is used to load a small part of image not whole content. We collect information to fill database. For me, we never touch image file.

Gilles

Judging from the backtrace I would assume the crash is from line 606 of imagescanner.cpp.

The code for KExiv2::getExif is here:
http://lxr.kde.org/source/KDE/kdegraphics/libs/libkexiv2/libkexiv2/kexiv2exif.cpp#073

Exiv2 bug 615: http://dev.exiv2.org/issues/show/615

I think this image has a makernote with the wrong tag type and Exiv2 reacts overly sensitive to that - I'll have to change the assertion to something more forgiving.

But I'd still like to see the image that causes this.

(This is the first real bug for 0.18 - I almost thought there are none left :)

-ahu.

*** Bug 182903 has been marked as a duplicate of this bug. ***

If bug 182903 is a duplicate, you should be able to trigger this bug with the rw2 photos I supplied for testing. I do not remember the URL where they were placed. Having a look at the output of digikam, it works fine indexing until it hits the first RAW picture.

ate Photos/2006, Oktober, 21/dscf0012.jpg"  : JPEG file identified
digikam(22181)/digikam (core) Digikam::ImageScanner::addImage: Adding new item "/media/Bueffel/Bilder/Private Photos/2006, Oktober, 21/dscf0012.jpg"
digikam(22181)/KEXIV2 KExiv2Iface::KExiv2::getImageDateTime: DateTime => Exif.Photo.DateTimeOriginal =>  QDateTime("Mi Nov 22 18:34:21 2006")
digikam(22181)/KEXIV2 KExiv2Iface::KExiv2::getDigitizationDateTime: DateTime (Exif digitalized):  Mi Nov 22 18:34:21 2006
digikam(22181)/KEXIV2 KExiv2Iface::KExiv2::getImageOrientation: Orientation => Exif.Image.Orientation =>  1
digikam(22181)/digikam (core) Digikam::DImg::load: "/media/Bueffel/Bilder/Private Photos/2008-12-26 Weihnachten 2008/p1000036.rw2"  : RAW file identified
digikam: tiffimage.cpp:688: static void Exiv2::Internal::TiffCreator::getPath(Exiv2::Internal::TiffPath&, uint32_t, uint16_t, uint32_t): Zusicherung »ts !=0« nicht erfüllt.
digikam: Fatal IO error: client killed

This is the image:

http://digikam3rdparty.free.fr/TEST_IMAGES/RAW/HORIZONTAL/p1000039.rw2

Does the console output in comment #10 go with bug #182903?

That's a different assertion (tiffimage.cpp:688) than the one in the original bug report here (tiffcomposite.cpp:697). From that console output it is clear that this is a side effect of my changes from last night, not a duplicate of this bug. Marcel is right in that it is also triggered by the call to ExifParser::encode from ImageScanner::loadFromDisk but the root cause here is different.

With this and Gilles' explanations in comment 6: Although the use case is valid and these are clearly bugs in Exiv2, I think we need to question the design now: Is it really desirable to call ExifParser::encode right after decoding the metadata and internally carry metadata in a binary container m_img? Why not keep it decoded in the Exiv2 metadata containers?

Since 0.18, ExifParser::encode is quite specific and powerful: 

http://dev.exiv2.org/repositories/entry/exiv2/trunk/src/exif.cpp#L463

It tries hard to encode the metadata into a binary block suitable for a JPEG image. E.g., it deletes certain tags which are not expected in JPEG images and tries to fit everything into 64kB. This is an expensive operation and may modify/lose metadata, especially if the source image is not a JPEG image. I would avoid doing this unless it is really needed. Why not decode the metadata when digiKam first loads the picture, keep it decoded in a metadata container all the while, and encode it only when needed for a specific binary target format.

I think such a design would minimize chances for errors, minimize the loss of metadata and maximize performance, since decode and encode are the most complex and expensive operations in Exiv2.

-ahu.

Andreas,

I'm agree that ExifParser::encode() is not the best solution here. But look code from KExiv2::getExif()

#if (EXIV2_TEST_VERSION(0,17,91))
            Exiv2::Blob blob;
            Exiv2::ExifParser::encode(blob, Exiv2::bigEndian, exif);
            QByteArray ba((const char*)&blob[0], blob.size());
#else
            Exiv2::DataBuf c2 = exif.copy();
            QByteArray ba((const char*)c2.pData_, c2.size_);
#endif

Before Exiv2 0.18, ExifData::copy() been available to. Now api has changed and you have recommended to use ExifParser::encode() instead... There is another alternative ?

Gilles

(In reply to comment #12)
> Does the console output in comment #10 go with bug #182903?

Yes.

For this discussion, copy and encode do the same thing and the issues described apply to both. What I suggest is an image lifecycle in digiKam which looks like this:

Load image -> decode metadata -> image processing -> encode metadata -> write image. Image processing should not encode / decode the metadata anymore.

Of course this picture is a simplistic one, without taking all the complexities of digiKam into account (I can do that, because I don't know them :)

-ahu.

A fix for Exiv2 bug 615 (http://dev.exiv2.org/issues/show/615) is in the Exiv2 SVN, r1743 (http://dev.exiv2.org/repositories/revision/exiv2/1743)

I think this fixes the original bug reported here, although we've not seen the offending image yet.

Daniel, can you please retest with the latest Exiv2 version from SVN and report if it works now?

-ahu.

Andreas, this is interesting info. This means that our current getExif implementation is not lossless and not reversible.

- what you suggest is storing ExifData, IptcData, XmpData directly? This is your intended workflow?
- these classes use std::vector internally, which means copying is always a deep copy? (We would have to write a wrapper for Qt-style shallow copies)
- should ExifParser::encode be used for JPEGs only when you say it removes certain tags?
- there are two ExifParser::encode methods. One has docs and says it does not do unintrusive writing, suggesting the other method. The other has no docs and requires a byte* buffer. Should this method be of any interest to us?

Re: comment #17: See bug #183171

-ahu.

Daniel, 

can you please test again with the latest Exiv2 version from SVN, recompile and install it. Do the same with libkexiv2 and report if crash disapear now?

Gilles Caulier

Sorry for silence, I was out without internet.

So, here is image that cause this crash:
ftp://mardan.home.pl/

I can't compile exiv2 from SVN right now, but maybe this image help to trace bug.

Can confirm that the crash is fixed by updating exiv2/libkexiv2.

Great, thx a lot for fix.