| Summary: | baloo_file_extractor crashes in libexiv in Exiv2::ValueType() on a particular file (attached) | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-baloo | Reporter: | Igor Zhuravlov <zhuravlov.ip> |
| Component: | Baloo File Daemon | Assignee: | Pinak Ahuja <pinak.ahuja> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | crash | CC: | bugs.kde.org, bugseforuns, Mathias.Homann, nate, rozzo, uli.wortmann |
| Priority: | NOR | ||
| Version: | 5.26.0 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
this file crashes baloo_file_extractor
this file crashes baloo_file_extractor |
||
|
Description
Igor Zhuravlov
2017-09-12 02:50:36 UTC
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 *** |