Baloo is stuck on indexing a single file and CPU usage is at 100%. When running balooctl status I see that it is always on the same file. I have attempted to use balooctl stop and balooctl suspend which did nothing, baloo_file continues to run. Reproducible: Always Steps to Reproduce: 1. Wait for baloo file indexing to begin. 2. 3. Actual Results: CPU usage is very high and baloo gets stuck on a single file. Expected Results: Baloo uses a moderate amount of CPU and completes indexing. Output from top: top - 08:14:23 up 16:46, 4 users, load average: 1.01, 1.07, 1.07 Tasks: 232 total, 2 running, 230 sleeping, 0 stopped, 0 zombie %Cpu(s): 3.9 us, 1.6 sy, 21.0 ni, 73.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 8055144 total, 4498724 used, 3556420 free, 1876 buffers KiB Swap: 2103292 total, 0 used, 2103292 free. 2976720 cached Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5678 msp 39 19 509572 45460 33588 R 106.7 0.564 137:19.51 baloo_file 1107 root 20 0 288020 64828 37716 S 6.667 0.805 4:37.97 X 1 root 20 0 35908 5816 3460 S 0.000 0.072 0:03.52 systemd Packages installed: baloo5-file-5.5.95-32.1.x86_64 baloo-pim-4.14.3-1.1.x86_64 baloo5-5.5.95-32.1.x86_64 baloo5-imports-5.5.95-32.1.x86_64 baloo-core-4.14.3-1.1.x86_64 baloo5-pim-5.1.2-1.1.x86_64 libbaloopim4-4.14.3-1.1.x86_64 libbaloowidgets4-4.14.3-1.1.x86_64 baloo5-tools-5.5.95-32.1.x86_64 libbalooqueryparser4-4.14.3-1.1.x86_64 baloo5-lang-5.5.95-32.1.noarch libbaloofiles4-4.14.3-1.1.x86_64 baloo5-kioslaves-5.5.95-32.1.x86_64 baloo-kioslaves-4.14.3-1.1.x86_64
Could you perhaps tell me more about that file?
I know that it is on the same file because the output of balooctl status does not change, but I don't know what file that is. Is there a log file or some other way to see which file is currently being indexed?
I just noticed that it is the baloo_file process that is taking too long. It's probably best for you to just attach a backtrace of the baloo_file process when it is consuming very high cpu $ sudo gdb --pid `pidof baloo_file` > thread apply all backtrace
I was able to reproduce the problem by setting the first run value to true in ~/.config/baloofilerc. Here is the backtrace. [New LWP 28075] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". 0x00007f4acb0e571e in ChertTable::find_in_block(unsigned char const*, Key, bool, int) () from /usr/lib64/libxapian.so.22 Thread 2 (Thread 0x7f4ab77f2700 (LWP 28075)): #0 0x00007f4ac84b24ad in poll () at /lib64/libc.so.6 #1 0x00007f4ac71b8322 in () at /usr/lib64/libxcb.so.1 #2 0x00007f4ac71b9def in xcb_wait_for_event () at /usr/lib64/libxcb.so.1 #3 0x00007f4ab974bc19 in () at /usr/lib64/qt5/plugins/platforms/libqxcb.so #4 0x00007f4ac8d3991f in () at /usr/lib64/libQt5Core.so.5 #5 0x00007f4ac81c23a4 in start_thread () at /lib64/libpthread.so.0 #6 0x00007f4ac84baa4d in clone () at /lib64/libc.so.6 Thread 1 (Thread 0x7f4acc6fc800 (LWP 28072)): #0 0x00007f4acb0e571e in ChertTable::find_in_block(unsigned char const*, Key, bool, int) () at /usr/lib64/libxapian.so.22 #1 0x00007f4acb0e6843 in ChertTable::find(Cursor*) const () at /usr/lib64/libxapian.so.22 #2 0x00007f4acb0c2979 in ChertCursor::find_entry(std::string const&) () at /usr/lib64/libxapian.so.22 #3 0x00007f4acb0ecdc3 in () at /usr/lib64/libxapian.so.22 #4 0x00007f4acb0f10fb in () at /usr/lib64/libxapian.so.22 #5 0x00007f4acb0d20ca in () at /usr/lib64/libxapian.so.22 #6 0x00007f4acb04a516 in Xapian::Document::Internal::get_value(unsigned int) const () at /usr/lib64/libxapian.so.22 #7 0x00007f4acb04a57c in Xapian::Document::get_value(unsigned int) const () at /usr/lib64/libxapian.so.22 #8 0x00007f4acb3ff37a in Baloo::XapianDocument::value(int) const (this=<optimized out>, slot=<optimized out>) at /usr/src/debug/baloo-5.5.95/src/xapian/xapiandocument.cpp:133 #9 0x000000000041fb03 in Baloo::BasicIndexingQueue::shouldIndex(Baloo::FileMapping&, QString const&) const () #10 0x0000000000420662 in Baloo::BasicIndexingQueue::process(Baloo::FileMapping&, QFlags<Baloo::UpdateDirFlag>) () #11 0x0000000000420bc4 in Baloo::BasicIndexingQueue::processNextIteration() () #12 0x00007f4ac8f44446 in QObject::event(QEvent*) () at /usr/lib64/libQt5Core.so.5 #13 0x00007f4ac9bd11dc in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5 #14 0x00007f4ac9bd61f0 in QApplication::notify(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5 #15 0x00007f4ac8f13dc5 in QCoreApplication::notifyInternal(QObject*, QEvent*) () at /usr/lib64/libQt5Core.so.5 #16 0x00007f4ac8f15c5f in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /usr/lib64/libQt5Core.so.5 #17 0x00007f4ac8f6bc83 in () at /usr/lib64/libQt5Core.so.5 #18 0x00007f4ac2621a04 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0 #19 0x00007f4ac2621c48 in () at /usr/lib64/libglib-2.0.so.0 #20 0x00007f4ac2621cec in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0 #21 0x00007f4ac8f6b0fc in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5 #22 0x00007f4ac8f11d1b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5 #23 0x00007f4ac8f193a6 in QCoreApplication::exec() () at /usr/lib64/libQt5Core.so.5 #24 0x0000000000418e2f in main ()
urgh. This is a bug in Xapian that I haven't been able to fix. The only way to fix this is to reset your Baloo database - $ balooctl disable $ balooctl enable *** This bug has been marked as a duplicate of bug 341581 ***