| Summary: | baloo_file_extractor crashes in Exiv2::DataValue::toLong() in kfilemetadata_exiv2extractor on specific image file | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kfilemetadata | Reporter: | Craig Denman <craig.a.denman> |
| Component: | general | Assignee: | Pinak Ahuja <pinak.ahuja> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | crash | CC: | a.stippich, nate, skierpage |
| Priority: | NOR | Keywords: | drkonqi |
| Version: | 5.54.0 | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Craig Denman
2019-02-19 18:05:04 UTC
Crashing in Exiv2::DataValue::toLong(), but called by KFileMetadata. It crashes in the exiv2 extractor, so likely reading from a corrupted image file. Can you determine the file at which it hangs using balooctl monitor? If you can provide the information requested in comment #2, please add it. A file that causes this crash can be found in the comment on this duped bug: https://bugs.kde.org/show_bug.cgi?id=405017#c4 *** Bug 405017 has been marked as a duplicate of this bug. *** I cannot figure out how to find the offending file. In the referenced bug report 40517 I see that I can use: Balooctl Status <filename> Is there a way to do something like a recursive scan to find the error. I am suspecting the installation directories at /usr/local/lib/node_modules where there are installations of electron, mathjax and npm. I would like to be able to scan the directory node-modules. On 3/12/19 2:43 PM, Nate Graham wrote: > https://bugs.kde.org/show_bug.cgi?id=404565 > > Nate Graham <nate@kde.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |skierpage@gmail.com > > --- Comment #5 from Nate Graham <nate@kde.org> --- > *** Bug 405017 has been marked as a duplicate of this bug. *** > You should be able to find the file when you type "balooctl monitor" in a console. It shows files that are currently indexed by baloo. If there is a crash somewhere, baloo monitor is usually stuck and shows the filename of the crashing file. KDE Frameworks 5.56 contains a change that may also fix your crash. Can you retest? Please provide the required info (In reply to Craig Denman from comment #6) > I cannot figure out how to find the offending file. I filed bug 405247 requesting some way to get baloo_file_extractor to report the problem file. In a terminal balooctl monitor balooctl disable # if it's not running balooctl enable and you should eventually get the crash report near the failure. (In reply to Alexander Stippich from comment #8) > KDE Frameworks 5.56 contains a change that may also fix your crash. Can you > retest? Alas brand-new Fedora 30 only ships KDE Frameworks 5.55.0. I may be able to rebuild the kf5-kfilemetadata srpm to newer Rawhide git commit 5.56 tag blurhg asdff, if I get a lot smarter ... :-) Fedora 30 updated to KDE Frameworks 5.57 (and exiv2-0.27.1), and bad news, I get a very similar crash as before when Baloo processes the problem panorama JPG from duplicate bug 405017 comment 4. Note that my crash stack seems similar but not identical to that of the original reporter of this bug. Dr Konqi reports Application: Baloo File Extractor (baloo_file_extractor), signal: Aborted Using host libthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7f0148b9c800 (LWP 10037))] ... Thread 1 (Thread 0x7f0148b9c800 (LWP 10037)): [KCrash Handler] #6 0x00007f014b81eeb5 in raise () from /lib64/libc.so.6 #7 0x00007f014b809895 in abort () from /lib64/libc.so.6 #8 0x00007f0139adf008 in std::__replacement_assert (__file=__file@entry=0x7f0139be4f60 "/usr/include/c++/9/bits/stl_vector.h", __line=__line@entry=1060, __function=__function@entry=0x7f0139c11ae0 "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=0x7f0139be4e10 "__builtin_expect(__n < this->size(), true)") at /usr/include/c++/9/x86_64-redhat-linux/bits/c++config.h:2510 #9 0x00007f0139b40415 in std::vector<unsigned char, std::allocator<unsigned char> >::operator[] (__n=<optimized out>, this=<optimized out>) at /usr/src/debug/exiv2-0.27.1-1.fc30.x86_64/src/value.cpp:257 #10 Exiv2::DataValue::write (os=..., this=<optimized out>) at /usr/src/debug/exiv2-0.27.1-1.fc30.x86_64/src/value.cpp:261 #11 0x00007f0139b40449 in Exiv2::DataValue::toLong (this=<optimized out>, n=<optimized out>) at /usr/include/c++/9/bits/stl_vector.h:1058 #12 0x00007f013a4fc8aa in KFileMetaData::Exiv2Extractor::fetchGpsAltitude (this=<optimized out>, data=...) at /usr/src/debug/kf5-kfilemetadata-5.57.0-1.fc30.x86_64/src/extractors/exiv2extractor.cpp:303 #13 0x00007f013a4fcf2f in KFileMetaData::Exiv2Extractor::extract (this=0x55e3fbe4b9d0, result=0x7ffc46deb470) at /usr/src/debug/kf5-kfilemetadata-5.57.0-1.fc30.x86_64/src/extractors/exiv2extractor.cpp:214 #14 0x000055e3faf495af in Baloo::App::index (this=this@entry=0x7ffc46debbc0, tr=0x55e3fc8eb220, url=..., id=id@entry=1391285936064515) at /usr/src/debug/kf5-baloo-5.57.0-1.fc30.x86_64/src/file/extractor/app.cpp:192 #15 0x000055e3faf4b7df in Baloo::App::processNextFile (this=0x7ffc46debbc0) at /usr/src/debug/kf5-baloo-5.57.0-1.fc30.x86_64/src/file/extractor/app.cpp:112 ... Please re-check with KF 5.58, another fix was added for the exivextractor there (Please re-open if it persists with 5.58) (In reply to Alexander Stippich from comment #12) > Please re-check with KF 5.58, another fix was added for the exivextractor > there Good news, Fedora 30 KDE spin updated to KDE Frameworks 5.58.0, and baloo_file_extractor doesn't crash on my panorama image any more. Thanks! *** This bug has been marked as a duplicate of bug 405210 *** |