Bug #1346

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

Added by Sanjay Rawat about 1 year ago. Updated 7 months 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 about 1 year 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 about 1 year 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 8 months 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 8 months ago

Thank you Robin for keeping an eye on them :)


Updated by Robin Mills 7 months 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