| Summary: | crash when loading certain image | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Christian Weiske <cweiske> |
| Component: | Metadata-Engine | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | ahuggel, caulier.gilles |
| Priority: | NOR | ||
| Version: | 0.9.1 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 7.3.0 | |
|
Description
Christian Weiske
2007-06-19 08:35:38 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 ?? () I'll post the bug in the exiv2 bugtracker. Could someone mark this as bogus? Christian, 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 Gilles, I am using 0.14 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 ok, seen your report in Exiv2 bugzilla. (:=))) http://dev.robotbattle.com/bugs/view.php?id=520 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... Gilles 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. -ahu. * Bugs are clearly from exiv2 if the command "exiv2 <image>" crashes. 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. Not reproducible with digiKam 7.3.0 and Exiv2 0.27.4 |