Bug 355238

Summary: Baloo crashes when file has timestamp 0
Product: [Frameworks and Libraries] frameworks-baloo Reporter: Anton Kreuzkamp <akreuzkamp>
Component: Baloo File DaemonAssignee: Christoph Cullmann <christoph>
Status: RESOLVED FIXED    
Severity: crash CC: aspotashev, christoph, me, pinak.ahuja, steve
Priority: NOR Keywords: drkonqi
Version: 5.16.0   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In: 5.27
Sentry Crash Report:

Description Anton Kreuzkamp 2015-11-12 12:20:32 UTC
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
Comment 1 Pinak Ahuja 2015-11-12 12:48:18 UTC
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
Comment 2 Anton Kreuzkamp 2015-11-12 13:41:52 UTC
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.
Comment 3 Anton Kreuzkamp 2015-11-13 00:51:20 UTC
[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
Comment 4 Pinak Ahuja 2015-11-13 06:07:13 UTC
So mtime and ctime can be zero due to file system screw ups, we should probably remove those asserts.
Comment 5 Vishesh Handa 2015-11-19 00:21:07 UTC
This is annoying. The mtime and ctime really shouldn't be 0.

Anyway, marking as confirmed.
Comment 6 Christoph Cullmann 2016-09-11 11:49:32 UTC
See

https://git.reviewboard.kde.org/r/128887/

time 0 is perfectly valid, this should never have been asserted.
Comment 7 Christoph Cullmann 2016-09-11 11:51:06 UTC
*** Bug 362333 has been marked as a duplicate of this bug. ***
Comment 8 Christoph Cullmann 2016-09-11 16:52:29 UTC
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
Comment 9 Christoph Cullmann 2016-09-11 16:53:23 UTC
Fixed ;=)
Comment 10 Boudhayan Gupta 2016-09-11 17:02:57 UTC
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?
Comment 11 Christoph Cullmann 2016-09-11 17:04:34 UTC
> 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.