Bug 26618 - SIGSEGV with ORF images (and PEF)
Summary: SIGSEGV with ORF images (and PEF)
Status: RESOLVED FIXED
Alias: None
Product: libopenraw
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: Other All
: medium major
Assignee: Hubert Figuiere
QA Contact:
URL:
Whiteboard: [release:0.1.0]
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-17 15:54 UTC by David Paleino
Modified: 2016-11-27 05:43 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Backtrace from gThumb using libopenraw (4.24 KB, text/plain)
2010-02-17 15:54 UTC, David Paleino
Details

Description David Paleino 2010-02-17 15:54:36 UTC
Created attachment 33380 [details]
Backtrace from gThumb using libopenraw

Hello,
I got this bug reported by a Debian user. libopenraw segfaults with .orf images. I tried with the user-supplied one [1], and one taken from an online website [2], and both make libopenraw segfault, with similar backtraces.

See below, backtrace from gthumb (attached).

However, compiling the examples in the source directory (ccfa.c and thumbc.c), with the image given in the Debian bugreport I get:

$ ./ccfa ~/p1080081.orf
data size = 9619532
data type = 5
$ ./thumbc ~/p1080081.orf
registering type 1
registering type 3
registering type 5
registering type 7
registering type 6
registering type 8
registering type 2
registering type 9
registering type 4
factory size 9
requested size 160
_enumThumbnailSizes init
_enumThumbnailSizes()
_locateDirs()
Identified ORF file
push offset =0x8
numEntries =21 shifting 254bytes
# dir found = 1
num of dirs 1
IFDDir::load() m_offset =8
_locateThumbnail
subtype 0
IFDDir::load() m_offset =8
no size found
error 5

While, with the image from [2], I get:

$ ./ccfa ~/300mm_f5.6.ORF 
data size = 12857600           
data type = 5                  
$ ./thumbc ~/300mm_f5.6.ORF 
registering type 1               
registering type 3               
registering type 5
registering type 7
registering type 6
registering type 8
registering type 2
registering type 9
registering type 4
factory size 9
requested size 160
_enumThumbnailSizes init
_enumThumbnailSizes()
_locateDirs()
Identified ORF file
push offset =0x8
numEntries =21 shifting 254bytes
push offset =0x680
numEntries =6 shifting 74bytes
# dir found = 2
num of dirs 2
IFDDir::load() m_offset =8
_locateThumbnail
subtype 0
IFDDir::load() m_offset =8
IFDDir::load() m_offset =680
_locateThumbnail
subtype 0
looking for JPEG at 13024
JPEG dimensions x=160 y=120
Found 160 pixels
_enumThumbnailSizes failed
current iter is 160
size 160 found
allocate s=11074 data =0
 data =0x9e8e130
Thumbnail in JPEG format, thumb size is 160, 120
short write
output 11074 bytes in 'thumb.jpg'
$

I'm going to see whether this could be a gThumb bug, but the backtrace starting from openraw makes me suspicious about that :) (even if, as I said in the Debian bugreport, gThumb 2.10.* used libopenraw too...)

Kindly,
David

[1] see the full buglog: http://bugs.debian.org/569788
[2] http://raw.fotosite.pl/download-Olympus_E-330_Sigma_135-400_f4.5-5.6/300mm_f5.6.ORF
Comment 1 Hubert Figuiere 2010-03-05 21:47:49 UTC
*** Bug 25464 has been marked as a duplicate of this bug. ***
Comment 2 Hubert Figuiere 2010-03-05 21:48:25 UTC
Also happen with PEF, see bug 25464
Comment 3 David Paleino 2010-03-05 21:57:28 UTC
Just to clarify: I gave a look, and gthumb 2.10 used libopenraw only for thumbnail generation, while using dcraw for showing the image. The bug appeared in 2.11 because it tries to use libopenraw also for showing the image.

I also ran valgrind against it, and it said something like it was writing 2 bytes off the calloc()'ed space. I'm unable to attach the valgrind output right now though (I believe I don't have it anymore) -- I'll generate a new one as soon as I get a slot of free time :)

David
Comment 4 David Paleino 2010-03-05 21:59:53 UTC
Ah, just before I forget (and going to bed again, even if it's almost morning here) -- the image attached to Debian's bugreport is no more available; you can get it at http://people.debian.org/~dapal/p1080081.orf .
Comment 5 Hubert Figuiere 2010-03-06 11:49:02 UTC
this is now fixed in git master.
Comment 6 Hubert Figuiere 2010-09-03 17:47:47 UTC
*** Bug 30006 has been marked as a duplicate of this bug. ***
Comment 7 Hubert Figuiere 2014-04-13 13:33:54 UTC
commit 1b15acdcfdc4664bc6c0be473cb6e096071a4e62


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.