Bug 248227

Summary: nepomuk strigi service crashes while indexing data
Product: [Unmaintained] nepomuk Reporter: George Kiagiadakis <mail>
Component: generalAssignee: Sebastian Trueg <sebastian>
Status: RESOLVED DUPLICATE    
Severity: crash CC: trueg
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Debian unstable   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description George Kiagiadakis 2010-08-18 11:18:21 UTC
Application: nepomukservicestub (0.2)
KDE Platform Version: 4.5.00 (KDE 4.5.0)
Qt Version: 4.6.3
Operating System: Linux 2.6.32-5-amd64 x86_64
Distribution: Debian GNU/Linux unstable (sid)

-- Information about the crash:
After I upgraded to kde 4.5, I decided to give nepomuk/strigi a try and enabled them. Indexing was going fine, until I saw that crash after a few days. I let it go the first time and the next day strigi started indexing again. After a few hours I saw the same crash. I let it go again. Again, today, the same, but this time I decided to report it. Note that the backtrace was exactly the same in all 3 crashes.

I noticed that after all three crashes, the virtuoso database was using 2.9 GB disk space (du -hs soprano-virtuoso.db). But when strigi started reindexing, the tray icon said that the database was using 2.8 GB. So, I guess that maybe it starts reindexing from a previous point in history and crashes always when it reaches a certain file. However, I can't find a log somewhere, so I don't know what really happens. If you can tell me how to debug, I could give it a try... I guess it will crash again after my next relogin...

The crash can be reproduced every time.

-- Backtrace:
Application: Nepomuk Service Stub (nepomukservicestub), signal: Aborted
__lll_lock_wait_private ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:97
	in ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S
[Current thread is 1 (Thread 0x7ff1e6102760 (LWP 3026))]

Thread 2 (Thread 0x7ff1d50f6710 (LWP 3133)):
[KCrash Handler]
#6  0x00007ff1e371e175 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#7  0x00007ff1e3720f80 in *__GI_abort () at abort.c:92
#8  0x00007ff1e37542bb in __libc_message (do_abort=<value optimized out>, fmt=<value optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#9  0x00007ff1e375db16 in malloc_printerr (action=3, str=0x7ff1e3814ac8 "double free or corruption (!prev)", ptr=<value optimized out>) at malloc.c:6267
#10 0x00007ff1e376288c in *__GI___libc_free (mem=<value optimized out>) at malloc.c:3739
#11 0x00007ff1e5b6041c in QString::free (d=0x281adc0) at tools/qstring.cpp:1108
#12 0x00007ff1e5b60852 in QString::operator= (this=0x1d06918, other=...) at tools/qstring.cpp:1282
#13 0x00007ff1d5dab081 in Nepomuk::IndexScheduler::updateDir (this=<value optimized out>, dir=..., analyzer=<value optimized out>, flags=<value optimized out>)
    at ../../../../nepomuk/services/strigi/indexscheduler.cpp:337
#14 0x00007ff1d5dabbab in Nepomuk::IndexScheduler::updateDir (this=0x1d068c0, dir=<value optimized out>, analyzer=0x7ff1d50f5e10, flags=) at ../../../../nepomuk/services/strigi/indexscheduler.cpp:421
#15 0x00007ff1d5dabbab in Nepomuk::IndexScheduler::updateDir (this=0x1d068c0, dir=<value optimized out>, analyzer=0x7ff1d50f5e10, flags=) at ../../../../nepomuk/services/strigi/indexscheduler.cpp:421
#16 0x00007ff1d5dabbab in Nepomuk::IndexScheduler::updateDir (this=0x1d068c0, dir=<value optimized out>, analyzer=0x7ff1d50f5e10, flags=) at ../../../../nepomuk/services/strigi/indexscheduler.cpp:421
#17 0x00007ff1d5dabbab in Nepomuk::IndexScheduler::updateDir (this=0x1d068c0, dir=<value optimized out>, analyzer=0x7ff1d50f5e10, flags=) at ../../../../nepomuk/services/strigi/indexscheduler.cpp:421
#18 0x00007ff1d5dabbab in Nepomuk::IndexScheduler::updateDir (this=0x1d068c0, dir=<value optimized out>, analyzer=0x7ff1d50f5e10, flags=) at ../../../../nepomuk/services/strigi/indexscheduler.cpp:421
#19 0x00007ff1d5dabbab in Nepomuk::IndexScheduler::updateDir (this=0x1d068c0, dir=<value optimized out>, analyzer=0x7ff1d50f5e10, flags=) at ../../../../nepomuk/services/strigi/indexscheduler.cpp:421
#20 0x00007ff1d5dad5b5 in Nepomuk::IndexScheduler::run (this=0x1d068c0) at ../../../../nepomuk/services/strigi/indexscheduler.cpp:314
#21 0x00007ff1e5b1be35 in QThreadPrivate::start (arg=0x1d068c0) at thread/qthread_unix.cpp:248
#22 0x00007ff1e34d68ba in start_thread (arg=<value optimized out>) at pthread_create.c:300
#23 0x00007ff1e37bb01d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#24 0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7ff1e6102760 (LWP 3026)):
#0  __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:97
#1  0x00007ff1e3764498 in _L_lock_9590 () from /lib/libc.so.6
#2  0x00007ff1e3762881 in *__GI___libc_free (mem=0x7ff1e3a48e40) at malloc.c:3737
#3  0x00007ff1e5c34b81 in socketNotifierSourceCheck (source=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:92
#4  0x00007ff1e2a0e8fa in g_main_context_check () from /lib/libglib-2.0.so.0
#5  0x00007ff1e2a0f2b3 in ?? () from /lib/libglib-2.0.so.0
#6  0x00007ff1e2a0f6ec in g_main_context_iteration () from /lib/libglib-2.0.so.0
#7  0x00007ff1e5c34713 in QEventDispatcherGlib::processEvents (this=0x1be7340, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:412
#8  0x00007ff1e400914e in QGuiEventDispatcherGlib::processEvents (this=0x7ff1e3a48e40, flags=<value optimized out>) at kernel/qguieventdispatcher_glib.cpp:204
#9  0x00007ff1e5c09a82 in QEventLoop::processEvents (this=<value optimized out>, flags=) at kernel/qeventloop.cpp:149
#10 0x00007ff1e5c09e5c in QEventLoop::exec (this=0x7ffffea97bc0, flags=) at kernel/qeventloop.cpp:201
#11 0x00007ff1e5c0eaeb in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1003
#12 0x0000000000403a57 in main (argc=<value optimized out>, argv=<value optimized out>) at ../../../nepomuk/servicestub/main.cpp:152

Possible duplicates by query: bug 245306, bug 243262, bug 242656, bug 240783, bug 237062.

Reported using DrKonqi
Comment 1 Sebastian Trueg 2010-09-08 09:30:15 UTC

*** This bug has been marked as a duplicate of bug 248244 ***