Project

General

Profile

Bug #8632

Directory offset out of bounds by exiv2

Added by sebix - Sebastian over 8 years ago. Updated about 8 years ago.

Status:
Closed: upstream
Priority:
Low
Assignee:
-
Category:
General
Start date:
Due date:
% Done:

0%

Estimated time:
Affected Version:
git development version
System:
unknown
bitness:
64-bit
hardware architecture:
amd64/x86

Description

This is a summary of the thread "Directory offset out of bounds?" on [Darktable-users].

Error is reproducable with the file attached.

According to Andreas Huggel (the main developer of Exiv2):
----
That's probably a shortcoming of Exiv2: It reads from JPEGs only what is officially the Exif segment and parses that. According to the Exif specification that is a self-contained block of information, however, some Makernotes contain pointers to locations outside of the Exif segment and the error that you encountered is generated if Exiv2 comes across such a pointer. It won't affect all the other information that Exiv2 reads from the Exif segment. It also doesn't happen in RAW files as these usually do not contain an Exif section and Exiv2 accesses the entire RAW image if necessary. It can however potentially mean that modifying the Exif data of such an image with Exiv2 will corrupt this part of the Makernote (the pointer may not be correct anymore after writing); that's the reason why the error is issued.

Unless you're a programmer and willing to improve how Exiv2 works in the described case, there is nothing you need to do about this. If the error bothers you, you can suppress it with the q flag.
---

Jeroen Hegeman:
----
I can confirm that exiv2 indeed issues a complaint. (Exiftool handles this fine, since exiftool appears to include decoding of the full Sony Makernote segment.) And DT crashes on it, indeed.

I suspect that where exiv2 adjusts some buffer size, DT does not, leading to the segfault. Any developer around who can confirm/check this?
----

In my opinion it has nothing to do with Sony (as my example shows)

part0.jpg (17.5 KB) part0.jpg sebix - Sebastian, 10/05/2012 07:19 PM

Related issues

Related to darktable - Bug #8642: V1.0 segfaults on import of imagesDuplicate

Has duplicate darktable - Bug #8640: Darktable segfaults on importingDuplicate

History

#1 Updated by jarda-wien - about 8 years ago

The crash happens only if there is a DNG file in the directory structure. I tried a KIPI-converted DNG and an ADOBE-converted DNG and both crash darktable upon import.

Off camera RAW works fine (Samsung NX10 - SRW files).

#2 Updated by Simon Spannagel about 8 years ago

  • Target version changed from 1.0.3 to Candidate for next patch release

#3 Updated by Tobias Ellinghaus almost 8 years ago

  • Affected Version set to git development version
  • % Done changed from 0 to 20
  • Status changed from New to Incomplete

Does this still happen?

#4 Updated by sebix - Sebastian almost 8 years ago

Unfortunately, yes. Using master / 39f5af70cfd93d9058e27d173a2aafa49d49b435
The file can be found on the Mailinglist and attached

(gdb) run ~/Desktop/img/part0.jpg
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /tmp/opt/dt/bin/darktable ~/Desktop/img/part0.jpg
[Thread debugging using libthread_db enabled]
[New Thread 0xb5cb8b70 (LWP 16224)]
[New Thread 0xb54b7b70 (LWP 16225)]
[New Thread 0xb4cb6b70 (LWP 16226)]
[New Thread 0xb44b5b70 (LWP 16227)]
[New Thread 0xb3cb4b70 (LWP 16228)]
[New Thread 0xb34b3b70 (LWP 16229)]
[New Thread 0xb2cb2b70 (LWP 16230)]
[New Thread 0xb24b1b70 (LWP 16231)]
[mipmap_cache] cache is empty, file `/home/sebastian/.cache/darktable/mipmaps-ebef8f9db326b3ddb45af1ef1615ba05f6682b0a' doesn't exist
[New Thread 0x59d1fb70 (LWP 16234)]
Error: Upper boundary of data for directory Photo, entry 0x920a is out of bounds: Offset = 0x000003dc, size = 8, exceeds buffer size by 6 Bytes; adjusting the size

Program received signal SIGSEGV, Segmentation fault.
0xb6ef7dcf in ?? () from /usr/lib/libexiv2.so.11

#5 Updated by Tobias Ellinghaus almost 8 years ago

  • Status changed from Incomplete to Triaged

Confirmed. Looks like a libexiv2 bug. At least it's their code that crashes.

#6 Updated by sebix - Sebastian almost 8 years ago

But one could catch the error and prevent dt from crashing?

#7 Updated by Tobias Ellinghaus almost 8 years ago

I have reported the bug upstream ([0]), let's see what the exiv2 folks think about it.

[0] http://dev.exiv2.org/issues/855

#8 Updated by Simon Spannagel over 7 years ago

  • System set to unknown
  • % Done changed from 20 to 0
  • Status changed from Triaged to Closed: upstream

Also available in: Atom PDF

Go to top