Bug #1346

Assertion failure in Exiv2::Internal::CiffComponent::doRead() in libexiv2

Added by Sanjay Rawat over 2 years ago. Updated almost 2 years ago.

image format
Target version:
Start date:
21 Apr 2018
Due date:
% Done:


Estimated time:
2.00 h


I found a failure assertion event in libevix2(0.26 001a00, 64 bit). To reproduce,
$ exiv2 input_file

The input that triggered the failure is attached.
GDB output: ====
@(gdb) r
Starting program: /usr/local/bin/exiv2 outd/crashInputs/exiv2-2018-04-06T00-08-51.535163.exi
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/".
exiv2: crwimage_int.cpp:241: virtual void Exiv2::Internal::CiffComponent::doRead(const byte*, uint32_t, uint32_t, Exiv2::ByteOrder): Assertion `dl directoryData || dl valueData' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff6e29c37 in GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007ffff6e29c37 in _GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff6e2d028 in __GI_abort () at abort.c:89
#2 0x00007ffff6e22bf6 in __assert_fail_base (fmt=0x7ffff6f77058 "%s%s%s:%u: s%sAssertion `%s' failed.\n%n",
assertion=assertion@entry=0x7ffff78cb080 "dl directoryData || dl valueData", file=file@entry=0x7ffff78cafd5 "crwimage_int.cpp", line=line@entry=241,
function=function@entry=0x7ffff78cb9a0 <Exiv2::Internal::CiffComponent::doRead(unsigned char const*, unsigned int, unsigned int, Exiv2::ByteOrder)::
> "virtual void Exiv2::Internal::CiffComponent::doRead(const byte*, uint32_t, uint32_t, Exiv2::ByteOrder)") at assert.c:92
#3 0x00007ffff6e22ca2 in GIassert_fail (assertion=0x7ffff78cb080 "dl directoryData || dl valueData", file=0x7ffff78cafd5 "crwimage_int.cpp", line=241,
function=0x7ffff78cb9a0 <Exiv2::Internal::CiffComponent::doRead(unsigned char const*, unsigned int, unsigned int, Exiv2::ByteOrder)::
_PRETTY_FUNCTION__> "virtual void Exiv2::Internal::CiffComponent::doRead(const byte*, uint32_t, uint32_t, Exiv2::ByteOrder)") at assert.c:101
#4 0x00007ffff77ad96f in Exiv2::Internal::CiffComponent::doRead(unsigned char const*, unsigned int, unsigned int, Exiv2::ByteOrder) () from /usr/local/lib/
#5 0x00007ffff77adb15 in Exiv2::Internal::CiffDirectory::readDirectory(unsigned char const*, unsigned int, Exiv2::ByteOrder) () from /usr/local/lib/
#6 0x00007ffff77b4997 in Exiv2::CrwParser::decode(Exiv2::CrwImage*, unsigned char const*, unsigned int) () from /usr/local/lib/
#7 0x00007ffff77b5258 in Exiv2::CrwImage::readMetadata() () from /usr/local/lib/
#8 0x000000000041bdfd in Action::Print::printSummary() ()
#9 0x000000000041e1a8 in Action::Print::run(std::string constx%x) ()
#10 0x0000000000406bba in main ()





Updated by Robin Mills over 2 years ago

  • Category set to image format
  • Status changed from New to Assigned
  • Assignee set to Robin Mills
  • Target version set to 0.27
  • % Done changed from 0 to 10
  • Estimated time set to 4.00 h

Thanks for reporting this. I've reproduced this and will investigate.


Updated by Robin Mills over 2 years ago

  • % Done changed from 10 to 50
  • Estimated time changed from 4.00 h to 2.00 h

Thanks for reporting this. I've replaced an assert with a throw and that makes the crash disappear. I'd like to discuss assert() with Team Exiv2. We have a new error mechanism in development at the moment and we should consider redefining assert() appropriately. Here's my fix:

540 rmills@rmillsmbp:~/gnu/github/exiv2/exiv2 $ git diff src/crwimage_int.cpp 
diff --git a/src/crwimage_int.cpp b/src/crwimage_int.cpp
index fae860f1..a85d2c08 100644
--- a/src/crwimage_int.cpp
+++ b/src/crwimage_int.cpp
@@ -238,7 +238,9 @@ namespace Exiv2 {
         tag_ = getUShort(pData + start, byteOrder);

         DataLocId dl = dataLocation();
-        assert(dl == directoryData || dl == valueData);
+        if ( dl != directoryData && dl != valueData ) {
+            throw Error(kerCorruptedMetadata);
+        }

         if (dl == valueData) {
             size_   = getULong(pData + start + 2, byteOrder);
541 rmills@rmillsmbp:~/gnu/github/exiv2/exiv2 $
I will raise an issue on GitHub about this and it will be fixed and tracked there. I'll close this issue when the GitHub version is resolved.


Updated by Robin Mills about 2 years ago

Sanjay: I'm reviewing all outstanding issues in preparation for Exiv2 v0.27 RC1 which will be released in October. There are 8 open issues on Redmine and 3 of them were reported by you. #1340, #1345 and #1346. They will receive attention before Exiv2 v0.27 GM which will be in December.


Updated by Sanjay Rawat about 2 years ago

Thank you Robin for keeping an eye on them :)


Updated by Robin Mills almost 2 years ago

  • Status changed from Assigned to Closed
  • % Done changed from 50 to 100

Fixed on 'master' and should be available on Exiv2 v0.27 RC2 available 2018-11-15

555 rmills@rmillsmbp:~/gnu/github/exiv2/master/build $ bin/exiv2 -pR ~/Downloads/exiv2-2018-04-06T00-08-51.535163.exi 
Exiv2 exception in print action for file /Users/rmills/Downloads/exiv2-2018-04-06T00-08-51.535163.exi:
Image type /Users/rmills/Downloads/exiv2-2018-04-06T00-08-51.535163.exi is not supported
556 rmills@rmillsmbp:~/gnu/github/exiv2/master/build $

Also available in: Atom PDF