Created attachment 107808 [details] this file crashes baloo_file_extractor > lsb-release -a LSB Version: n/a Distributor ID: openSUSE project Description: openSUSE Leap 42.2 Release: 42.2 Codename: n/a > uname -a Linux myhostname 4.4.79-18.26-default #1 SMP Thu Aug 10 20:30:05 UTC 2017 (fa5a935) x86_64 x86_64 x86_64 GNU/Linux > rpm -qa | egrep 'baloo|exiv2' baloo5-file-5.26.0-2.1.x86_64 libexiv2-14-0.25-6.1.x86_64 baloo5-widgets-16.08.2-1.1.x86_64 exiv2-debugsource-0.25-6.1.x86_64 baloo5-5.26.0-2.1.x86_64 baloo5-file-debuginfo-5.26.0-2.1.x86_64 baloo5-imports-5.26.0-2.1.x86_64 baloo5-lang-5.26.0-2.1.noarch libexiv2-14-debuginfo-0.25-6.1.x86_64 baloo5-kioslaves-5.26.0-2.1.x86_64 baloo5-tools-5.26.0-2.1.x86_64 > balooctl index /home/myusername/tmp/src/php-7.1.1/ext/exif/tests/bug60150.jpg Ошибка сегментирования (core dumped) > sudo journalctl -f ... Sep 08 16:19:52 myhostname kernel: baloo_file_extr[11311]: segfault at 4 ip 00007f9e5e239a68 sp 00007ffcff6880b8 error 4 in libexiv2.so.14.0.0[7f9e5e105000+2c7000] Sep 08 16:20:42 myhostname systemd-coredump[12138]: Process 11311 (baloo_file_extr) of user 1000 dumped core. > coredumpctl gdb 11311 ... Core was generated by `/usr/bin/baloo_file_extractor'. Program terminated with signal SIGSEGV, Segmentation fault. £0 Exiv2::ValueType<std::pair<unsigned int, unsigned int> >::toFloat (this=0x57a0910, n=0) at /usr/src/debug/exiv2-0.25/include/exiv2/value.hpp:1695 1695 ok_ = (value_[n].second != 0); [Current thread is 1 (Thread 0x7f9e6dd4c880 (LWP 11311))] Missing separate debuginfos, use: zypper install ... (gdb) l 1690 } 1691 // Specialization for unsigned rational 1692 template<> 1693 inline float ValueType<URational>::toFloat(long n) const 1694 { 1695 ok_ = (value_[n].second != 0); 1696 if (!ok_) return 0.0f; 1697 return static_cast<float>(value_[n].first) / value_[n].second; 1698 } 1699 // Default implementation (gdb) p value_ $1 = {<std::_Vector_base<std::pair<unsigned int, unsigned int>, std::allocator<std::pair<unsigned int, unsigned int> > >> = { _M_impl = {<std::allocator<std::pair<unsigned int, unsigned int> >> = {<__gnu_cxx::new_allocator<std::pair<unsigned int, unsigned int> >> = {<No data fields>}, <No data fields>}, _M_start = 0x0, _M_finish = 0x0, _M_end_of_storage = 0x0}}, <No data fields>} (gdb) p n $2 = 0 (gdb) bt £0 0x00007ffff4e0f20d in poll () at /lib64/libc.so.6 £1 0x00007ffff3830314 in () at /usr/lib64/libglib-2.0.so.0 £2 0x00007ffff383042c in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0 £3 0x00007ffff571c31c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5 £4 0x00007ffff56c9feb in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5 £5 0x00007ffff56d1ed6 in QCoreApplication::exec() () at /usr/lib64/libQt5Core.so.5 £6 0x000000000040841b in main(int, char**) (argc=1, argv=0x7fffffffdaf8) at /usr/src/debug/baloo-5.26.0/src/file/extractor/main.cpp:57 (gdb) quit
Created attachment 107829 [details] this file crashes baloo_file_extractor
Yet another file getting baloo_file_extractor to crash: > rpm -qa | egrep 'baloo|lmdb' baloo5-file-5.26.0-2.1.x86_64 baloo5-widgets-16.08.2-1.1.x86_64 baloo5-5.26.0-2.1.x86_64 lmdb-debugsource-0.9.14-5.4.x86_64 baloo5-imports-5.26.0-2.1.x86_64 baloo5-lang-5.26.0-2.1.noarch liblmdb-0_9_14-0.9.14-5.4.x86_64 baloo5-kioslaves-5.26.0-2.1.x86_64 liblmdb-0_9_14-debuginfo-0.9.14-5.4.x86_64 baloo5-file-debuginfo-5.26.0-2.1.x86_64 baloo5-tools-5.26.0-2.1.x86_64 > balooctl index /home/myusername/j64-806/addons/labs/labs/examples/data/toolbar.bmp Ошибка сегментирования (core dumped) > sudo journalctl -f ... Sep 13 10:49:58 myhostname kernel: traps: balooctl[31242] general protection ip:7fc7794549d9 sp:7fff89fa2fe0 error:0 in liblmdb-0.9.14.so[7fc779449000+13000]traps: Sep 13 10:49:59 myhostname systemd-coredump[31244]: Process 31242 (balooctl) of user 1000 dumped core. > coredumpctl gdb 31242 ... Core was generated by `balooctl index /home/myusername/j64-806/addons/labs/labs/examples/data/toolbar.bmp'. Program terminated with signal SIGSEGV, Segmentation fault. £0 0x00007fc7794549d9 in mdb_txn_commit (txn=0x69616d5f74726174) at mdb.c:3207 3207 if (txn == NULL || txn->mt_env == NULL) [Current thread is 1 (Thread 0x7fc77b93f880 (LWP 31242))] Missing separate debuginfos, use: zypper install ... (gdb) l 3202 { 3203 int rc; 3204 unsigned int i; 3205 MDB_env *env; 3206 3207 if (txn == NULL || txn->mt_env == NULL) 3208 return EINVAL; 3209 3210 if (txn->mt_child) { 3211 rc = mdb_txn_commit(txn->mt_child); (gdb) p txn $1 = (MDB_txn *) 0x69616d5f74726174 (gdb) p txn.mt_env Cannot access memory at address 0x69616d5f74726194 (gdb) bt £0 0x00007fc7794549d9 in mdb_txn_commit (txn=0x69616d5f74726174) at mdb.c:3207 £1 0x00007fc7794549f0 in mdb_txn_commit (txn=0x40475b) at mdb.c:3211 £2 0x00007fc77b32304e in Baloo::Transaction::commit() (this=this@entry=0x7fff89fa35b0) at /usr/src/debug/baloo-5.26.0/src/engine/transaction.cpp:266 £3 0x00000000004087b7 in main(int, char**) (argc=3, argv=<optimized out>) at /usr/src/debug/baloo-5.26.0/src/tools/balooctl/main.cpp:220 (gdb) quit
I think I hit the same issue. In my logs, I find that on every boot, I get baloo_file_extr[2217]: segfault at 4 ip 0000003186d5da58 sp 00007ffcf0cd6d38 error 4 in libexiv2.so.14.0.0[3186c00000+2b7000] I assume there is some file causing this. Possible duplicate: Bug 370172 So, please mark as confirmed for 5.37.0. (I'm using Gentoo.)
Erik, to identify problem file the following approach may be used: 1. stop baloo indexing by command: balooctl stop 2. reboot, log in 3. start baloo monitoring in separate console by command: balooctl monitor 4. start system journal monitoring in separate console by command: sudo journalctl -f 5. start baloo indexing again by command: balooctl start When journalctl will show baloo_file_extr error, then baloo hangs so the last 1-2-3 names displayed by baloo monitor are the best candidates to check by command: balooctl index
(In reply to Igor Zhuravlov from comment #4) > When journalctl will show baloo_file_extr error, then baloo hangs so the > last 1-2-3 names displayed by baloo monitor are the best candidates to check > by command: balooctl index Ok, I tried this, but I get the response “Skipping: /path/file.ext Reason: Already scheduled for indexing” or, after stopping/disabling and enabling/starting baloo again, “Baloo Index could not be opened”.
> “Baloo Index could not be opened”. It seems like baloo cannot reset to initial state. After "balooctl disable" ensure: - files ~/.config/baloo* - dir ~/.local/share/baloo/ - running baloo* processes are absent. If not, then try to restart the parent subsystem akonadi too, e.g. by this: 1) stop akonadi by "akonadictl stop", 2) kill baloo* akonadi* file.so and mysqld processes if there are any, 3) remove files and dir specified above manually, 4) reboot, 5) login as user, 6) check akonadi status by "akonadictl status" and start it manually by "akonadictl start" if it's not running yet, 7) enable baloo by "balooctl enable", 8) start baloo by "balooctl start".
It seems all the candidates found by looking at the journal and balooctl monitor are already indexed[*]; I can't seem to find the culprit :-( [*] Skipping: /path/to/file.ext Reason: Already indexed
Hmm, the command "balooctl disable" wipes dir ~/.local/share/baloo/ where indexed data are stored. So, if disabling and then enabling commands have fulfilled correctly then full reindexing must start since the index is empty.
Even if I couldn't find the file that causes the error for me, Igor provided sufficient material for a developer to seriously look at this issue. That is what needs to happen at this point.
*** Bug 389679 has been marked as a duplicate of this bug. ***
*** Bug 397199 has been marked as a duplicate of this bug. ***
*** Bug 390824 has been marked as a duplicate of this bug. ***
*** Bug 361186 has been marked as a duplicate of this bug. ***
The original issue brought up here was fixed recently in Bug 352856. The crash mentioned in comment 2 is a separate one, which is tracked with Bug 389679. *** This bug has been marked as a duplicate of bug 352856 ***