Using krunner, if I start editing a program I recently called, then krunner crashes with the following backtrace: #0 0x00007fffc228e59d in mdb_dbi_open () at /usr/lib64/liblmdb-0.9.11.so #1 0x00007fffc24a8637 in Baloo::PostingDB::open(MDB_txn*) () at /usr/lib64/libKF5BalooEngine.so.5 #2 0x00007fffc249d456 in Baloo::Database::open(Baloo::Database::OpenMode) () at /usr/lib64/libKF5BalooEngine.so.5 #3 0x00007fffc28f2ec8 in () at /usr/lib64/libKF5Baloo.so.5 #4 0x00007fffc28e52c2 in Baloo::Query::exec() () at /usr/lib64/libKF5Baloo.so.5 #5 0x00007fffc2b05216 in () at /usr/lib64/qt5/plugins/krunner_baloosearchrunner.so #6 0x00007fffc2b05d90 in () at /usr/lib64/qt5/plugins/krunner_baloosearchrunner.so #7 0x00007fffce4cc116 in Plasma::AbstractRunner::performMatch(Plasma::RunnerContext&) () at /usr/lib64/libKF5Runner.so.5 #8 0x00007fffce2aeba0 in ThreadWeaver::Executor::run(QSharedPointer<ThreadWeaver::JobInterface> const&, ThreadWeaver::Thread*) () at /usr/lib64/libKF5ThreadWeaver.so.5 #9 0x00007fffce2ad930 in ThreadWeaver::Job::execute(QSharedPointer<ThreadWeaver::JobInterface> const&, ThreadWeaver::Thread*) () at /usr/lib64/libKF5ThreadWeaver.so.5 #10 0x00007fffce2acf3a in ThreadWeaver::Thread::run() () at /usr/lib64/libKF5ThreadWeaver.so.5 #11 0x00007ffff433c4ff in QThreadPrivate::start(void*) (arg=0xae2250) at thread/qthread_unix.cpp:331 #12 0x00007ffff1b5e0a4 in start_thread () at /lib64/libpthread.so.0 #13 0x00007ffff3cc808d in clone () at /lib64/libc.so.6 Reproducible: Always Steps to Reproduce: 1. Start krunner. 2. Type a program name recently called. 3. Edit it quickly. Actual Results: krunner crashes. Expected Results: krunner works. This must also affect plasmashell, as it often crashes if I type program names in kicker.
I ran into this issue too, with baloo-5.15.0.
Sorry, I forgot to mention that I'm using baloo-core-4.14.
*** Bug 354511 has been marked as a duplicate of this bug. ***
*** Bug 354569 has been marked as a duplicate of this bug. ***
I am seeing this same crash, but in plasmashell which is very annoying. It doesn't always start itself afterward. I am using kubuntu 15.10 with baloo 5.15.0. It happens intermittently, but often enough to be bothersome. Here is the stacktrace for the thread of plasmashell that caused the crash: Thread 10 (Thread 0x7f5fbffff700 (LWP 7807)): [KCrash Handler] #6 0x00007f5fcc299c23 in mdb_dbi_open () at /usr/lib/x86_64-linux-gnu/liblmdb.so.0 #7 0x00007f5fcc4bb507 in Baloo::PostingDB::open(MDB_txn*) () at /usr/lib/x86_64-linux-gnu/libKF5BalooEngine.so.5 #8 0x00007f5fcc4aeeb9 in Baloo::Database::open(Baloo::Database::OpenMode) () at /usr/lib/x86_64-linux-gnu/libKF5BalooEngine.so.5 #9 0x00007f5fcc912dd8 in () at /usr/lib/x86_64-linux-gnu/libKF5Baloo.so.5 #10 0x00007f5fcc904a09 in Baloo::Query::exec() () at /usr/lib/x86_64-linux-gnu/libKF5Baloo.so.5 #11 0x00007f5fccb28f3f in SearchRunner::match(Plasma::RunnerContext&, QString const&, QString const&) (this=this@entry=0x4263ab0, context=..., type=..., category=...) at ../../../runners/baloo/baloosearchrunner.cpp:98 #12 0x00007f5fccb29b18 in SearchRunner::match(Plasma::RunnerContext&) (this=0x4263ab0, context=...) at ../../../runners/baloo/baloosearchrunner.cpp:164 #13 0x00007f5fe15e8540 in Plasma::AbstractRunner::performMatch(Plasma::RunnerContext&) () at /usr/lib/x86_64-linux-gnu/libKF5Runner.so.5 #14 0x00007f5fe13cbc70 in ThreadWeaver::Executor::run(QSharedPointer<ThreadWeaver::JobInterface> const&, ThreadWeaver::Thread*) () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #15 0x00007f5fe13ca8b0 in ThreadWeaver::Job::execute(QSharedPointer<ThreadWeaver::JobInterface> const&, ThreadWeaver::Thread*) () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #16 0x00007f5fe13ca35a in ThreadWeaver::Thread::run() () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #17 0x00007f60a04972be in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #18 0x00007f609f5746aa in start_thread (arg=0x7f5fbffff700) at pthread_create.c:333 #19 0x00007f609fda3eed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
*** Bug 355034 has been marked as a duplicate of this bug. ***
Created attachment 95395 [details] plasmashell-20151108-205938.kcrash.txt Same here, plasma just crashed right after starting kmail. qt-5.5.1, frameworks-5.15, plasma-5.4.2, kde-apps-15.08
Created attachment 95578 [details] proposed patch I get this crash, even if Baloo is disabled in the kcm. In my case, there is no database, Database::open fails (as expected), but it is then called from several threads concurrently, so weird things start to happen : for example a thread just returned from mdb_env_create, then in the other Database::open succeeds since m_env isn't null, so the second thread can start transactions on an MDB_env* which hasn't been fully initialized. So I think Database::open should be protected by a mutex. There is a memory leak too : in error cases Database::open resets m_env without calling mdb_env_close.
I too disable indexing because my home directory has far too many files for indexing to work well for me. I was able to stop the crashes on my system by renaming/deleting the following files and folders while logged out of kde: ~/.config/.baloofilerc ~/.config/.baloofileinformation ~/.kde/share/config/baloorc ~/.kde/share/config/baloofilerc ~/.kde/share/config/baloofileinformationrc This file was recreated and was identical to the old file: ~/.config/.baloofileinformation This file was recreated but was missing a line (initialIndexingDone=true) ~/.kde/share/config/baloorc I would say that for anyone having the problem: check if your baloorc file has "initialIndexingDone=true" and remove that line to see if the crashes stop.
Even if the crashes seems to have stopped in 5.17, I think parts of my patch still applies : - Database::open isn't threadsafe - if mdb_env_open fails, m_env is leaked (see mdb_env_open documentation)
*** Bug 365976 has been marked as a duplicate of this bug. ***
Loïc Yhuel, your are right, funny enough, I made a similar patch and already submitted it. https://git.reviewboard.kde.org/r/128890/
*** This bug has been marked as a duplicate of bug 356298 ***
(In reply to Christoph Cullmann from comment #12) > Loïc Yhuel, your are right, funny enough, I made a similar patch and already > submitted it. > > https://git.reviewboard.kde.org/r/128890/ However, the m_env leak when mdb_env_open fails is still there.
I don't think you are allowed to call close then.
http://104.237.133.194/doc/group__mdb.html#ga32a193c6bf4d7d5c5d579e71f22e9340 "If this function fails, mdb_env_close() must be called to discard the MDB_env handle."
You beat me, will add it! Thanks for the doc link, thought have read that part.
Git commit 377e62b0307839edb0245d65381a3f55f594ae4e by Christoph Cullmann. Committed on 11/09/2016 at 20:30. Pushed by cullmann into branch 'master'. add missing close env, as pointed out by Loïc Yhuel Missed in my review diff :/ REVIEW: 128890 M +1 -0 src/engine/database.cpp http://commits.kde.org/baloo/377e62b0307839edb0245d65381a3f55f594ae4e
=> Thanks again, really thought have read that part now 10 times but just forgot it :P