Bug #797
A crash can occur with certain JPEGs.
Start date:
16 Nov 2011
Due date:
% Done:
100%
Estimated time:
Description
Steps to reproduce:
- With any valid application or test harness program that incorporates exiv2, load the attached image.
- With the same application or test harness as in step one, try to extract all the exif data from the image.
- With the same application or test harness, try to add a tag and observe the results.
Notice that the following assertion fails:
tiffcomposite.cpp:1049: virtual uint32_t Exiv2::Internal::TiffBinaryArray::doCount() const: Assertion `typeSize != 0' failed.
We're seeing this in Shotwell.
Files
Associated revisions
#797: Truncate entries with an out-of-bounds upper boundary, rather than trying to adjust their size.
History
Updated by Andreas Huggel about 10 years ago
- Status changed from New to Assigned
- Assignee set to Andreas Huggel
Thanks for reporting this. Checked in a change similar to the proposed patch, consistent with what is done elsewhere.
However, the sample picture also seems to expose another issue:
$ exiv2 -q -pa -gExif.Image.ImageDescription dsc03961.jpg Exif.Image.ImageDescription Ascii 30 SONY DSC $ exiv2 -q -M'set Exif.Image.ImageDescription Hello' dsc03961.jpg $ exiv2 -q -pa -gExif.Image.ImageDescription dsc03961.jpg Exif.Image.ImageDescription Ascii 6 SONY D
Updated by Andreas Huggel about 10 years ago
The reason why the image description is not set as expected is due to the invalid entry 0x5239 in directory SonyMinolta. Its value overwrites the modified tag and re-instates the original value. I think changing the logic how we deal with out-of-bounds values is appropriate: if it doesn't look right, truncate it, rather than trying to adjust the size.
Updated by Andreas Huggel about 10 years ago
- Status changed from Assigned to Resolved
- Target version set to 0.23
- % Done changed from 0 to 100
#797: TiffBinaryArray::doCount(): Replaced assertion with a check for type size which sets it to 1 for unknown types. (Clint Rogers)