Application: baloo_file (5.16.0) (Compiled from sources) Qt Version: 5.6.0 Operating System: Linux 4.2.5-1-ARCH x86_64 Distribution (Platform): Archlinux Packages -- Information about the crash: - What I was doing when the application crashed: Starting the Plasma session. The crash happens after a minute or two. What I found out is that the docId in Frame #11 is always the same: 68743270854821892. I guess that's a specific file on my disk. If you tell me how to find out, I'm glad to tell you which file it is (and probably provide it to you). :) The crash can be reproduced every time. -- Backtrace: Application: Baloo File Indexing Daemon (baloo_file), signal: Aborted Using host libthread_db library "/usr/lib/libthread_db.so.1". [Current thread is 1 (Thread 0x7f64cbb83840 (LWP 552))] Thread 3 (Thread 0x7f64cbb81700 (LWP 555)): #0 0x00007f64d58ad18d in poll () from /usr/lib/libc.so.6 #1 0x00007f64d07d0fbc in ?? () from /usr/lib/libglib-2.0.so.0 #2 0x00007f64d07d10cc in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0x00007f64d698160c in QEventDispatcherGlib::processEvents (this=0x7f64c40008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:419 #4 0x00007f64d69047e8 in QEventLoop::processEvents (this=0x7f64cbb80cf0, flags=...) at kernel/qeventloop.cpp:128 #5 0x00007f64d6904ae4 in QEventLoop::exec (this=0x7f64cbb80cf0, flags=...) at kernel/qeventloop.cpp:204 #6 0x00007f64d66d1e6e in QThread::exec (this=0x7f64d7eb1920 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at thread/qthread.cpp:503 #7 0x00007f64d7e1b3da in QDBusConnectionManager::run (this=0x7f64d7eb1920 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at qdbusconnection.cpp:152 #8 0x00007f64d66d9c65 in QThreadPrivate::start (arg=0x7f64d7eb1920 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at thread/qthread_unix.cpp:329 #9 0x00007f64d46024a4 in start_thread () from /usr/lib/libpthread.so.0 #10 0x00007f64d58b613d in clone () from /usr/lib/libc.so.6 Thread 2 (Thread 0x7f64cb07e700 (LWP 572)): [KCrash Handler] #6 0x00007f64d58005f8 in raise () from /usr/lib/libc.so.6 #7 0x00007f64d5801a7a in abort () from /usr/lib/libc.so.6 #8 0x00007f64d66c50df in qt_message_fatal (context=..., message=...) at global/qlogging.cpp:1610 #9 0x00007f64d66c17aa in QMessageLogger::fatal (this=0x7f64cb07d950, msg=0x7f64d69ed970 "ASSERT: \"%s\" in file %s, line %d") at global/qlogging.cpp:784 #10 0x00007f64d66ba8ca in qt_assert (assertion=0x7f64d6efd93f "info.mTime", file=0x7f64d6efd8b8 "/home/anton/devel/kde/frameworks/baloo/src/engine/documenttimedb.cpp", line=61) at global/qglobal.cpp:3044 #11 0x00007f64d6edfedc in Baloo::DocumentTimeDB::put (this=0x7f64cb07da70, docId=68743270854821892, info=...) at /home/anton/devel/kde/frameworks/baloo/src/engine/documenttimedb.cpp:61 #12 0x00007f64d6ef54b0 in Baloo::WriteTransaction::addDocument (this=0x7f637c002f90, doc=...) at /home/anton/devel/kde/frameworks/baloo/src/engine/writetransaction.cpp:80 #13 0x00007f64d6ef0f07 in Baloo::Transaction::addDocument (this=0x7f64cb07db10, doc=...) at /home/anton/devel/kde/frameworks/baloo/src/engine/transaction.cpp:226 #14 0x000000000044356a in Baloo::FirstRunIndexer::run (this=0x147e560) at /home/anton/devel/kde/frameworks/baloo/src/file/firstrunindexer.cpp:76 #15 0x00007f64d66d3689 in QThreadPoolThread::run (this=0x147e6e0) at thread/qthreadpool.cpp:93 #16 0x00007f64d66d9c65 in QThreadPrivate::start (arg=0x147e6e0) at thread/qthread_unix.cpp:329 #17 0x00007f64d46024a4 in start_thread () from /usr/lib/libpthread.so.0 #18 0x00007f64d58b613d in clone () from /usr/lib/libc.so.6 Thread 1 (Thread 0x7f64cbb83840 (LWP 552)): #0 0x00007f64d58ad18d in poll () from /usr/lib/libc.so.6 #1 0x00007f64d07d0fbc in ?? () from /usr/lib/libglib-2.0.so.0 #2 0x00007f64d07d10cc in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0x00007f64d698160c in QEventDispatcherGlib::processEvents (this=0x1455ad0, flags=...) at kernel/qeventdispatcher_glib.cpp:419 #4 0x00007f64d69047e8 in QEventLoop::processEvents (this=0x7fff3e4fead0, flags=...) at kernel/qeventloop.cpp:128 #5 0x00007f64d6904ae4 in QEventLoop::exec (this=0x7fff3e4fead0, flags=...) at kernel/qeventloop.cpp:204 #6 0x00007f64d690868e in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1272 #7 0x000000000043a7ca in main (argc=1, argv=0x7fff3e4fef38) at /home/anton/devel/kde/frameworks/baloo/src/file/main.cpp:88 Possible duplicates by query: bug 354472, bug 351119, bug 349696, bug 348367, bug 347577. Reported using DrKonqi
Hmm, this is strange. Somehow the timeinfo object doesn't have any mTime information. You can check which file it is by running: balooshow 68743270854821892 in the terminal
Heh, that looks like a hint! :) [anton@kdab_akrp ~]$ balooshow 68743270854821892 The fileID is not equal to the actual Baloo fileID This is a bug GivenID: 68743270854821892 ActualID: 0 GivenINode: 16005540 ActualINode: 0 GivenDeviceID: 2052 ActualDeviceID: 0 No index information found [anton@kdab_akrp ~]$ find /home/anton -inum 16005540 /home/anton/Backups/N9 - 15-08-23/Nokia N9 The inode belongs to a directory.
[anton@kdab_akrp ~]$ ls -la Backups/N9\ -\ 15-08-23/ [...] drwxr-xr-x 29 anton anton 4096 Jan 1 1970 Nokia N9 hehe... strange, but it seems those things happen in a file system :D
So mtime and ctime can be zero due to file system screw ups, we should probably remove those asserts.
This is annoying. The mtime and ctime really shouldn't be 0. Anyway, marking as confirmed.
See https://git.reviewboard.kde.org/r/128887/ time 0 is perfectly valid, this should never have been asserted.
*** Bug 362333 has been marked as a duplicate of this bug. ***
Git commit 628daced19b88d0c537736a14aea3287a4662609 by Christoph Cullmann. Committed on 11/09/2016 at 16:48. Pushed by cullmann into branch 'master'. allow ctime/mtime == 0 Fix that baloo is instant killed by any file with timestamp 0. (which is OK and can easily happen after unpacking some zip/tar/..) REVIEW: 128887 M +17 -0 autotests/unit/engine/documenttimedbtest.cpp M +0 -2 src/engine/documenttimedb.cpp M +0 -3 src/engine/writetransaction.cpp http://commits.kde.org/baloo/628daced19b88d0c537736a14aea3287a4662609
Fixed ;=)
Thanks for pushing the fix. I see you didn't wait for the Shipit ;-) In any case, an mtime/ctime value of 0 isn't illegal - it means 0 time units after the unix epoch. Is there any reason the asserts were there other than to just crash on potential filesystem bugs?
> In any case, an mtime/ctime value of 0 isn't illegal - it means 0 time units after the unix epoch. Is there any reason the asserts were there other than to just crash on potential filesystem bugs? I guess there are there because of some misunderstanding that 0 is not allowed. But given that any tar archive might contain such timestamps, it is very bad to assert on that.