SUMMARY *** ~ gdb baloo_file GNU gdb (GDB) 12.1 Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from baloo_file... Reading symbols from /home/ *snip* /.cache/debuginfod_client/8e3c1fa7eac4da47ae410c92534e553266eb033c/debuginfo... (gdb) run --nofork Starting program: /usr/bin/baloo_file --nofork [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". [New Thread 0x7ffff27ff640 (LWP 3065)] [New Thread 0x7ffff1dfd640 (LWP 3066)] [New Thread 0x7ffff15fc640 (LWP 3067)] [Detaching after fork from child process 3068] kf.baloo: "/home/ *snip* " id seems to have changed. Perhaps baloo was not running, and this file was deleted + re-created kf.baloo.engine: PositionDB::put MDB_PAGE_NOTFOUND: Requested page not found kf.baloo.engine: PostingDB::put MDB_BAD_TXN: Transaction must abort, has a child, or is invalid kf.baloo.engine: PositionDB::put MDB_BAD_TXN: Transaction must abort, has a child, or is invalid *snip (a lot of the same output)* kf.baloo.engine: PostingDB::put MDB_BAD_TXN: Transaction must abort, has a child, or is invalid kf.baloo.engine: PositionDB::put MDB_BAD_TXN: Transaction must abort, has a child, or is invalid kf.baloo.engine: Transaction::commit MDB_BAD_TXN: Transaction must abort, has a child, or is invalid [Detaching after fork from child process 3072] kf.baloo: "/home/ *snip (it was the same file)* " id seems to have changed. Perhaps baloo was not running, and this file was deleted + re-created kf.baloo.engine: PostingDB::put MDB_PAGE_NOTFOUND: Requested page not found kf.baloo.engine: PositionDB::put MDB_BAD_TXN: Transaction must abort, has a child, or is invalid *snip (a lot of the same output)* kf.baloo.engine: PositionDB::put MDB_BAD_TXN: Transaction must abort, has a child, or is invalid kf.baloo.engine: Transaction::commit MDB_BAD_TXN: Transaction must abort, has a child, or is invalid [Detaching after fork from child process 3076] kf.baloo: "/home/ *snip (it was still the same file)* " id seems to have changed. Perhaps baloo was not running, and this file was deleted + re-created kf.baloo.engine: PositionDB::put MDB_PAGE_NOTFOUND: Requested page not found kf.baloo.engine: PostingDB::put MDB_BAD_TXN: Transaction must abort, has a child, or is invalid kf.baloo.engine: PositionDB::put MDB_BAD_TXN: Transaction must abort, has a child, or is invalid *snip (a lot of the same output)* kf.baloo.engine: PostingDB::put MDB_BAD_TXN: Transaction must abort, has a child, or is invalid kf.baloo.engine: PositionDB::put MDB_BAD_TXN: Transaction must abort, has a child, or is invalid kf.baloo.engine: Transaction::commit MDB_BAD_TXN: Transaction must abort, has a child, or is invalid mdb.c:7881: Assertion '!((size_t)srcnode & 1)' failed in mdb_node_move() Thread 4 "Thread (pooled)" received signal SIGABRT, Aborted. [Switching to Thread 0x7ffff15fc640 (LWP 3067)] __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 44 return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0; (gdb) backtrace #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007ffff708e3d3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78 #2 0x00007ffff703e838 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007ffff7028535 in __GI_abort () at abort.c:79 #4 0x00007ffff7673624 in ?? () from /usr/lib/liblmdb.so #5 0x00007ffff766e647 in ?? () from /usr/lib/liblmdb.so #6 0x00007ffff766fb88 in mdb_cursor_del () from /usr/lib/liblmdb.so #7 0x00007ffff76708c4 in mdb_txn_commit () from /usr/lib/liblmdb.so #8 0x00007ffff7dadc2c in Baloo::Transaction::commit (this=this@entry=0x7ffff15fb970) at /usr/src/debug/baloo-5.94.0/src/engine/transaction.cpp:276 #9 0x000055555557885b in Baloo::FileContentIndexerProvider::markFailed (id=10164018631213827, this=<optimized out>) at /usr/src/debug/baloo-5.94.0/src/file/filecontentindexerprovider.cpp:38 #10 Baloo::FileContentIndexer::run (this=<optimized out>) at /usr/src/debug/baloo-5.94.0/src/file/filecontentindexer.cpp:86 #11 0x00007ffff78e8521 in QThreadPoolThread::run (this=0x555555622580) at thread/qthreadpool.cpp:100 #12 0x00007ffff78e435a in QThreadPrivate::start (arg=0x555555622580) at thread/qthread_unix.cpp:331 #13 0x00007ffff708c54d in start_thread (arg=<optimized out>) at pthread_create.c:442 #14 0x00007ffff7111874 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100 (gdb) *** STEPS TO REPRODUCE 1. Run baloo_file (on startup or from shell) OBSERVED RESULT Crash EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: 5.18.3-arch1-1 (64-bit) (available in About System) KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.4 ADDITIONAL INFORMATION Always crashes after system startup
I deleted baloo db manually (just removed the whole ~/.local/share/baloo folder) and then did a new first run and now it works properly.
Somewhere along the line, someone would have recommended deleting the index and starting again from scratch. Quite often by saying to try "balooctl purge" There *are* still instances of MDB_BAD_TXN reported but thankfully far, far fewer than a couple of years back. It's a report from LMDB library and suggests a corruption of the index. The "markFailed" seen in the dump should generate a "Not able to commit to DB, DB likely is in a bad state. Exiting" failure - but the process crashes first. You are on Arch, do you have it set up using BTRFS? If so, there's a test you can do that might give a hint (baloo can struggle with BTRFS and multiple subvols), see: https://bugs.kde.org/show_bug.cgi?id=402154#c12 If you are running into this, baloo will be reindexing your files after each reboot (not fully reindexing every time, but will be thinking it has 8 to 10 different discs that appear and disappear again and it needs to do a lot of "catching up"). This can make the index, and memory usage, pretty large...
Thanks for the thorough explanation and info! I'm using ext4 as a filesystem. BTW: I was working on a personal project and did a git reset --hard and changed the directory and file structure just before the bug started occuring if my memory serves me right. "kf.baloo: "/home/ *snip (it was the same file)* " id seems to have changed. Perhaps baloo was not running, and this file was deleted + re-created" ^^^ and this was one of the project files. It might have already been broken though since it insinuates that baloo might not have been running while the file was deleted + re-created. Now I don't know if this has anything to do with the corruption of the index (I also installed and then removed some packages during the same session) but these are just some things I remember doing before it started crashing on startup.
(In reply to Valtti Rinnemaa from comment #3) > BTW: I was working on a personal project and did a git reset --hard and > changed the directory and file structure just before the bug started > occuring if my memory serves me right. Baloo should be able to cope if a file is deleted and another "appear" with the same inode. Normally it would be told of changes via iNotify but if it misses the notification, it would normally catch up after a relogon or "balooctl check". However it can get a bit stressed with "large scale" deletions. It can be that deletions "overflow" the iNotify queue - that is more than "sysctl fs.inotify.max_queued_events" happen. Also if there are a *load* of deletions these can take a while to process. I met this with Bug 437754. Your "git reset" might have been a bit hard on Baloo :-/
> However it can get a bit stressed with "large scale" deletions. It can be > that deletions "overflow" the iNotify queue - that is more than "sysctl > fs.inotify.max_queued_events" happen. Also if there are a *load* of > deletions these can take a while to process. I met this with Bug 437754. > > Your "git reset" might have been a bit hard on Baloo :-/ Well it was just a few small text files so it doesn't sound likely. I also haven't done any "large scale" deletions or loads of deletions recently. I can't really think of anything out of the ordinary I would have done on my system that would have caused the corruption. It has been working fine now though.
(In reply to Valtti Rinnemaa from comment #5) > ... it was just a few small text files so it doesn't sound likely ... Ok, I'll admit that was a bit of guesswork. If you are back working, is it OK to close the bug report?
(In reply to tagwerk19 from comment #6) > If you are back working, is it OK to close the bug report? Yes it's fine by me!
(In reply to Valtti Rinnemaa from comment #7) > (In reply to tagwerk19 from comment #6) > > If you are back working, is it OK to close the bug report? > > Yes it's fine by me! Closing...