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
*** Bug 25464 has been marked as a duplicate of this bug. ***
Also happen with PEF, see bug 25464
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
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 .
this is now fixed in git master.
*** Bug 30006 has been marked as a duplicate of this bug. ***
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.