Bug 406229 - baloo_file_extractor crashes in Exiv2::Internal::TiffReader::readTiffEntry() on a specific TIFF file
Summary: baloo_file_extractor crashes in Exiv2::Internal::TiffReader::readTiffEntry() ...
Status: RESOLVED UPSTREAM
Alias: None
Product: frameworks-kfilemetadata
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.56.0
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Pinak Ahuja
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-04 18:23 UTC by Nicolas Fella
Modified: 2019-05-21 03:10 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Backtrace (5.16 KB, text/plain)
2019-04-04 18:23 UTC, Nicolas Fella
Details
Backtrace with debug symbols (6.61 KB, text/plain)
2019-04-06 15:52 UTC, Nicolas Fella
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas Fella 2019-04-04 18:23:38 UTC
Created attachment 119243 [details]
Backtrace

SOFTWARE/OS VERSIONS

KDE Plasma Version: 5.15.3
KDE Frameworks Version: 5.56
Qt Version: 5.12.2

ADDITIONAL INFORMATION
Comment 1 Nicolas Fella 2019-04-04 18:28:32 UTC
I was able to pinpoint the crash to a file: https://cgit.kde.org/digikam.git/tree/core/tests/metadataengine/data/20160821035715.jpg
Comment 2 Nate Graham 2019-04-05 13:19:02 UTC
Crashing in Exiv2::Internal::TiffReader::readTiffEntry. It's interesting that you say it crashes on a JPEG file, because KFileMetadata was trying to open it as a TIFF. It's possible this is fixed in git master/5.57 due to improvements in file type detection; can you test?
Comment 3 Nicolas Fella 2019-04-06 15:52:09 UTC
Created attachment 119273 [details]
Backtrace with debug symbols
Comment 4 Nicolas Fella 2019-04-06 15:52:40 UTC
Still happens with Neon unstable
Comment 5 Nate Graham 2019-04-06 15:58:18 UTC
Relevant part of the backtrace:

#17 0x00007fd23bcada06 in Exiv2::TiffParser::decode(Exiv2::ExifData&, Exiv2::IptcData&, Exiv2::XmpData&, unsigned char const*, unsigned int) () from /usr/lib/x86_64-linux-gnu/libexiv2.so.26
#18 0x00007fd23bc29330 in Exiv2::ExifParser::decode(Exiv2::ExifData&, unsigned char const*, unsigned int) () from /usr/lib/x86_64-linux-gnu/libexiv2.so.26
#19 0x00007fd23bc43170 in Exiv2::JpegBase::readMetadata() () from /usr/lib/x86_64-linux-gnu/libexiv2.so.26
#20 0x00007fd24004d208 in KFileMetaData::Exiv2Extractor::extract (this=0x5639d84966f0, result=0x7ffece28b320) at ./src/extractors/exiv2extractor.cpp:163
#21 0x00005639d6eb022f in Baloo::App::index (this=this@entry=0x7ffece28bac0, tr=0x5639d8abbc80, url=..., id=id@entry=5642697968715777) at ./src/file/extractor/app.cpp:192
#22 0x00005639d6eb0b8e in Baloo::App::processNextFile (this=0x7ffece28bac0) at ./src/file/extractor/app.cpp:112


So Exiv2 first (correctly) tries the JPEG extractor, then switches to the TIFF extractor for some reason, then crashes.

At this point it feels like the issue is in Exiv2 itself, not Baloo or KFileMetadata, both of which have done their part as much as they're able. Can you file a bug with the Exiv2 folks? The fully symbolicated backtrace you attached will probably be very useful for them. Thanks!
Comment 6 Nicolas Fella 2019-04-06 21:43:33 UTC
Looks like the issue is resolved in exiv master
Comment 7 Nate Graham 2019-04-06 22:01:01 UTC
Do you have a link to the commit handy? Then I can see about prodding the discrete release distros to patch their Exiv packages.
Comment 8 Nicolas Fella 2019-04-06 22:08:12 UTC
Sorry, I don't