SUMMARY I dragged some files from my camera onto my drive, and the Crash Reporting Assistant popped up to report that baloo_file_extractor had crashed. STEPS TO REPRODUCE 1. Drag a bunch of files from camera via MTP to indexed drive. OBSERVED RESULT Crash Reporting Assistant popped up. After installing debuginfo (and fixing https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Fedora ), the crash report indicates the crash is in kfilemetadata_exiv2extractor: #6 0x00007f09a8cb253f in raise () from /lib64/libc.so.6 #7 0x00007f09a8c9c895 in abort () from /lib64/libc.so.6 #8 0x00007f0993dd6278 in std::__replacement_assert (__file=__file@entry=0x7f0993eeff08 "/usr/include/c++/8/bits/stl_vector.h", __line=__line@entry=950, __function=__function@entry=0x7f0993f4c740 <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=0x7f0993eefed8 "__builtin_expect(__n < this->size(), true)") at /usr/include/c++/8/x86_64-redhat-linux/bits/c++config.h:2389 #9 0x00007f0993e8dc85 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 0x00007f0993e8dcb9 in Exiv2::DataValue::toLong (this=<optimized out>, n=<optimized out>) at /usr/include/c++/8/bits/stl_vector.h:948 #12 0x00007f0998615529 in ?? () from /usr/lib64/qt5/plugins/kf5/kfilemetadata/kfilemetadata_exiv2extractor.so Unfortunately, the Baloo file indexing machinery gives no indication what file it's working on when there's a crash. EXPECTED RESULT No crash SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 5.14.4 KDE Frameworks Version: 5.54.0 Qt Version: 5.11.3 ADDITIONAL INFORMATION I know the 59 files that I dragged in that seemed to trigger this crash. Is there some way to run baloo_file_extractor on each, one by one? (I couldn't find any documentation for this program.) If I run `balooctl index <filename>` for each one, it mostly reports "Already scheduled for indexing".
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 ***