Bug 146948 - crash when loading certain image
Summary: crash when loading certain image
Alias: None
Product: digikam
Classification: Unclassified
Component: Metadata-Engine (show other bugs)
Version: 0.9.1
Platform: Gentoo Packages Linux
: NOR crash (vote)
Target Milestone: ---
Assignee: Digikam Developers
Depends on:
Reported: 2007-06-19 08:35 UTC by Christian Weiske
Modified: 2021-05-04 06:07 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.3.0


Note You need to log in before you can comment on or make changes to this bug.
Description Christian Weiske 2007-06-19 08:35:38 UTC
Version:           0.9.1 (using KDE KDE 3.5.5)
Installed from:    Gentoo Packages
OS:                Linux

The subject image is at http://tmp.cweiske.de/kaputtFotos2007%20124.jpg.

When having it (and some others from the same camera) in digikam, it crashes on startup when scanning the collection.

Calling showfoto to display the picture crashes it.

cweiske:/data/grafik> showfoto kaputtFotos2007\ 124.jpg
QFile::open: No file name specified
QFile::open: No file name specified
Warning: Makernote tag 0xfe7f has invalid Exif type 65518; using 7 (undefined).
Warning: Makernote tag 0x5000 has invalid Exif type 1058; using 7 (undefined).
Warning: Makernote tag 0x8255 has invalid Exif type 15500; using 7 (undefined).
terminate called after throwing an instance of 'std::length_error'
  what():  basic_string::_S_create
KCrash: Application 'showfoto' crashing...
KCrash cannot reach kdeinit, launching directly.
Comment 1 Christian Weiske 2007-06-19 08:37:58 UTC
Seems as if that is a bug in exiv2 as it crashes also:

(gdb) run kaputtFotos2007\ 124.jpg
Starting program: /usr/bin/exiv2 kaputtFotos2007\ 124.jpg
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...Warning: Makernote tag 0xfe7f has invalid Exif type 65518; using 7 (undefined).
Warning: Makernote tag 0x5000 has invalid Exif type 1058; using 7 (undefined).
Warning: Makernote tag 0x8255 has invalid Exif type 15500; using 7 (undefined).
terminate called after throwing an instance of 'std::length_error'
  what():  basic_string::_S_create

Program received signal SIGABRT, Aborted.
0xb7f2c410 in ?? ()
(gdb) bt
#0  0xb7f2c410 in ?? ()
#1  0xbf99752c in ?? ()
#2  0x00000006 in ?? ()
#3  0x00003b79 in ?? ()
#4  0xb7c0a6b1 in raise () from /lib/libc.so.6
#5  0xb7c0bde8 in abort () from /lib/libc.so.6
#6  0xb7deb220 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6
#7  0xb7de8ce5 in std::set_unexpected(void (*)()) () from /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6
#8  0xb7de8d22 in std::terminate() () from /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6
#9  0xb7de8e5a in __cxa_throw () from /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6
#10 0xb7d81bef in std::__throw_length_error(char const*) () from /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6
#11 0xb7dc5370 in std::string::_Rep::_S_create(unsigned, unsigned, std::allocator<char> const&) ()
   from /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6
#12 0xb7dc60f9 in std::string::_S_copy_chars(char*, __gnu_cxx::__normal_iterator<char*, std::string>, __gnu_cxx::__normal_iterator<char*, std::string>) () from /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6
#13 0xb7dc6211 in std::string::string(char const*, unsigned, std::allocator<char> const&) ()
   from /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6
#14 0xb7eec5b2 in Exiv2::StringValueBase::read(unsigned char const*, long, Exiv2::ByteOrder) () from /usr/lib/libexiv2.so.0
#15 0xb7e8fa28 in Exiv2::Exifdatum::setValue(Exiv2::Entry const&, Exiv2::ByteOrder) () from /usr/lib/libexiv2.so.0
#16 0xb7e8fb11 in Exiv2::Exifdatum::Exifdatum(Exiv2::Entry const&, Exiv2::ByteOrder) () from /usr/lib/libexiv2.so.0
#17 0xb7e94196 in Exiv2::ExifData::add(__gnu_cxx::__normal_iterator<Exiv2::Entry const*, std::vector<Exiv2::Entry, std::allocator<Exiv2::Entry>---Type <return> to continue, or q <return> to quit---
 > >, __gnu_cxx::__normal_iterator<Exiv2::Entry const*, std::vector<Exiv2::Entry, std::allocator<Exiv2::Entry> > >, Exiv2::ByteOrder) ()
   from /usr/lib/libexiv2.so.0
#18 0xb7e947ae in Exiv2::ExifData::load(unsigned char const*, long) () from /usr/lib/libexiv2.so.0
#19 0xb7eac867 in Exiv2::JpegBase::readMetadata() () from /usr/lib/libexiv2.so.0
#20 0x080564d1 in std::string Exiv2::toString<int>(int const&) ()
#21 0x0805e55c in std::string Exiv2::toString<int>(int const&) ()
#22 0x080506c1 in ?? ()
#23 0xb7bf7838 in __libc_start_main () from /lib/libc.so.6
#24 0x0804b391 in ?? ()
Comment 2 Christian Weiske 2007-06-19 08:42:28 UTC
I'll post the bug in the exiv2 bugtracker. Could someone mark this as bogus?
Comment 3 caulier.gilles 2007-06-19 08:53:59 UTC

This problem has been already reported in this room. If you use Exiv2 library 0.12, please update at least to 0.13.

Gilles Caulier
Comment 4 Christian Weiske 2007-06-19 09:05:54 UTC
Gilles, I am using 0.14
Comment 5 caulier.gilles 2007-06-19 09:31:28 UTC
If you have open a file here, no need to duplicate it on Exiv2 (excepted if Andreas want it of course)

If you can, try to provide more informations like :

- the CPU info (if 64 bits for ex.)
- the compilation option used with Exiv2.
- a valgrind backtrace of crash running under digiKam. Look here for more info: http://www.digikam.org/?q=contrib
- a pictures witch crash Exiv2
- try to reproduce the crash to use Exiv2 command line tool.

Question: witch libkexiv2 library you use ? I recommend the last stable available on http://www.kipi-plugins.org. I have fixed some bugs in the pass.

I have CC Andreas (who is Exiv2 author). He is registered on digiKam bugzilla and have already fixed some Exiv2 bugs using this room...

Gilles Caulier
Comment 6 caulier.gilles 2007-06-19 09:35:49 UTC
ok, seen your report in Exiv2 bugzilla. (:=)))


It sound like a bug in Exiv2 library like Exiv2 command line tool crash. This is not relevant of libkexiv2 and digiKAm.

My previous remarks still valid. Post future comments on Exiv2 bugzilla. Thanks in advance for your help. I close this file...

Comment 7 Andreas Huggel 2007-06-19 11:38:20 UTC
Christian, thanks for reporting this.

Gilles is right, this appears to be a duplicate of #144574. It is fixed in SVN,  I have marked the exiv2 bug as a duplicate and closed it. Please reopen the exiv2 bug if it still happens with exiv2 from SVN.

Generally, if a problem is clearly from exiv2 (like this one*), it's better to report it to the exiv2 bugtracker as Christian did, so that we don't take time away from the digikam developers.
If it's not very clear where the root cause of the problem is, it's better to discuss it here. I'm on digikam devel and if I overlook something here, Gilles will surely notify me ;) If such a problem turns out to be an exiv2 issue, I usually open another bug there an point to the digikam bug.


* Bugs are clearly from exiv2 if the command "exiv2 <image>" crashes.
Comment 8 Mark Purcell 2007-06-19 13:37:16 UTC
The bug in digikam I would like to see fixed here is better handling of when libexiv2 crashes.  I understand that has been discussed before, but it is obviously going to be an ongoing issue as new bugs are discovered in dependant libraries.
Comment 9 caulier.gilles 2021-05-04 06:07:08 UTC
Not reproducible with digiKam 7.3.0 and Exiv2 0.27.4