Summary: | baloo_file_extractor crash, in Exiv2::DataValue::toLong in kfilemetadata_exiv2extractor | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-baloo | Reporter: | skierpage <skierpage> |
Component: | Baloo File Daemon | Assignee: | baloo-bugs-null |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | a.stippich, nate, skierpage |
Priority: | NOR | ||
Version: | 5.54.0 | ||
Target Milestone: | --- | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
Latest Commit: | https://phabricator.kde.org/R286:6e449d44bb5dd7aca58464306d0b7da1312be8ee | Version Fixed In: | 5.56 |
Attachments: |
New crash information added by DrKonqi
New crash information added by DrKonqi |
Description
skierpage
2019-03-03 02:59:51 UTC
You can run `balooctl status` to see which file it crashes on. (In reply to Nate Graham from comment #1) > You can run `balooctl status` to see which file it crashes on. That didn't help, it just prints the status of the index. Instead I moved all the pictures to (unindexed) /tmp, then `balooctl disable`, `balooctl enable`, and after it had caught up, I moved each file back in a loop. It's crashing on a 6.5 MB Google Panorama photo. I then ran `balooctl index ~/Pictures/2019/PANO_20190217_130422.vr.jpg` and got a third crash: Indexing /home/spage/Pictures/2019/PANO_20190217_130422.vr.jpg /usr/include/c++/8/bits/stl_vector.h:950: std::vector<_Tp, _Alloc>::const_reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) const [with _Tp = unsigned char; _Alloc = std::allocator<unsigned char>; std::vector<_Tp, _Alloc>::const_reference = const unsigned char&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n < this->size(), true)' failed. KCrash: Application 'balooctl' crashing... I'll try to link in the Crash Reporting Assistant and attach the big image... Created attachment 118659 [details]
New crash information added by DrKonqi
balooctl (5.55.0) using Qt 5.11.3
Crash when I ran `balooctl index path/to/PANO_img.vr.jpg`
-- Backtrace (Reduced):
#8 0x00007f9c0e3d3278 in std::__replacement_assert (__file=__file@entry=0x7f9c0e4ecf08 "/usr/include/c++/8/bits/stl_vector.h", __line=__line@entry=950, __function=__function@entry=0x7f9c0e549740 <std::vector<unsigned char, std::allocator<unsigned char> >::operator[](unsigned long) const::__PRETTY_FUNCTION__> "std::vector<_Tp, _Alloc>::const_reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) const [with _Tp = unsigned char; _Alloc = std::allocator<unsigned char>; std::vector"..., __condition=__condition@entry=0x7f9c0e4eced8 "__builtin_expect(__n < this->size(), true)") at /usr/include/c++/8/x86_64-redhat-linux/bits/c++config.h:2389
#9 0x00007f9c0e48ac85 in std::vector<unsigned char, std::allocator<unsigned char> >::operator[] (__n=<optimized out>, this=<optimized out>) at /usr/src/debug/exiv2-0.26-12.fc29.x86_64/src/value.cpp:229
#10 Exiv2::DataValue::write (os=..., this=<optimized out>) at /usr/src/debug/exiv2-0.26-12.fc29.x86_64/src/value.cpp:233
#11 0x00007f9c0e48acb9 in Exiv2::DataValue::toLong (this=<optimized out>, n=<optimized out>) at /usr/include/c++/8/bits/stl_vector.h:948
#12 0x00007f9c20a3d56c in KFileMetaData::Exiv2Extractor::fetchGpsAltitude (this=<optimized out>, data=...) at /usr/include/c++/8/ext/aligned_buffer.h:74
The Google Pixel 2 panorama JPG file that crashes baloo file indexer is too big to attach at 6,502,554 bytes. It's on https://www.skierpage.com/ in a folder named /bugs, named PANO_20190217_130422.vr.jpg , together with another panorama that's smaller that *doesn't* crash named PANO_20190217_130355.vr.jpg. The crasher is 9112x1670 pixels. The rest of the data reported by ImageMagick's `identify -verbose` seems pretty similar. BTW as comment 3 indicates Fedora upgraded me to a newer version of Plasma/Frameworks than the original comment. Maybe this bug should be refiled against exiv2-libs, perhaps in http://dev.exiv2.org/projects/exiv2/issues ? But I tried all variations of `exiv2 print -p s|a|e|t|v|h|i|x|c|p|C|R|S|X PANO_bad.jpg` and got no crashes. Created attachment 118727 [details]
New crash information added by DrKonqi
baloo_file_extractor (5.55.0) using Qt 5.11.3
- What I was doing when the application crashed:
On restart I guess baloo tried to index a problem file again, and it reported a crash.
The backtrace includes Exiv2Extractor:fetchGpsAltitude. `exiv2 print -p a`reports pretty similar GPSAltitude info in the problem file compared to a working panorama, so maybe it isn't the value but the structure or size of the image and its metadata.
-- Backtrace (Reduced):
#8 0x00007f1620856278 in std::__replacement_assert (__file=__file@entry=0x7f162096ff08 "/usr/include/c++/8/bits/stl_vector.h", __line=__line@entry=950, __function=__function@entry=0x7f16209cc740 <std::vector<unsigned char, std::allocator<unsigned char> >::operator[](unsigned long) const::__PRETTY_FUNCTION__> "std::vector<_Tp, _Alloc>::const_reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) const [with _Tp = unsigned char; _Alloc = std::allocator<unsigned char>; std::vector"..., __condition=__condition@entry=0x7f162096fed8 "__builtin_expect(__n < this->size(), true)") at /usr/include/c++/8/x86_64-redhat-linux/bits/c++config.h:2389
#9 0x00007f162090dc85 in std::vector<unsigned char, std::allocator<unsigned char> >::operator[] (__n=<optimized out>, this=<optimized out>) at /usr/src/debug/exiv2-0.26-12.fc29.x86_64/src/value.cpp:229
#10 Exiv2::DataValue::write (os=..., this=<optimized out>) at /usr/src/debug/exiv2-0.26-12.fc29.x86_64/src/value.cpp:233
#11 0x00007f162090dcb9 in Exiv2::DataValue::toLong (this=<optimized out>, n=<optimized out>) at /usr/include/c++/8/bits/stl_vector.h:948
#12 0x00007f1620fcb56c in KFileMetaData::Exiv2Extractor::fetchGpsAltitude (this=<optimized out>, data=...) at /usr/include/c++/8/ext/aligned_buffer.h:74
*** This bug has been marked as a duplicate of bug 404565 *** This should be fixed by https://phabricator.kde.org/R286:6e449d44bb5dd7aca58464306d0b7da1312be8ee which was included in KF 5.56 (In reply to Alexander Stippich from comment #7) > This should be fixed by > https://phabricator.kde.org/R286:6e449d44bb5dd7aca58464306d0b7da1312be8ee > which was included in KF 5.56 Sadly I still get a crash with KDE Frameworks 5.57. I left this as a duplicate and added the new stack trace to bug 404565 comment 11. KDE Frameworks 5.58.0 seems to have fixed the crash \o/ *** This bug has been marked as a duplicate of bug 405210 *** |