Summary: | nepomukservicestub (nepomukstorage) crashes with SEGV | ||
---|---|---|---|
Product: | nepomuk | Reporter: | Jonathan Thomas <echidnaman> |
Component: | storage | Assignee: | Sebastian Trueg <sebastian> |
Status: | RESOLVED UPSTREAM | ||
Severity: | crash | CC: | ismailyilmaz1978, jtamate, me, trueg |
Priority: | NOR | ||
Version: | 4.4 | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Unspecified | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | Nepomuk crash report (apport text file with .crash extension) |
Description
Jonathan Thomas
2010-03-30 22:46:44 UTC
Can this crash still be reproduced? I've queried the downstream bug, though it may be hard to tell whether or not it is still around since Dr. Konqi can't catch nepomukservicestub crashes, and the Ubuntu crash handler that has been catching these has been disabled for final release. For what it's worth, the downstream bug garnered one duplicate report from KDE 4.4.2. The response to my query: "Yes this crash can be reproduced in Lucid Lynx with KDE 4.4.5 (and even with KDE 4.5 RC2). To give you a hint, this crash occurs when system language is set to Turkish language. When system language is reverted back to English, the crash dissappears and nepomuk+strigi works correctly." I am using Kubuntu Lucid Lynx (10.04) on two of my machines (a desktop PC and a netbook) with two different KDE versions (4.4.5 and 4.5 RC2) and this crash can be reproduced on both machines on every login. From my experiences as a user, I can confirm that this bug is alive since KDE 4.4 beta stages (started when virtuoso/soprano first introduced) and it never get fixed. From my experiences, I suspect that this is mainly because this bug affects only some machines with some specific locales. I am using Kubuntu in Turkish (tr) and this crash occurs when system language (not KDE UI)is set to Turkish: Nepomuk crashes, strigi gets disabled and akonadi cannot be started, also Dolphin nepomuk interface disables too. And when the system language is reverted back to English, the Nepomuk, Strigi, Dolphin nepomuk tagging/search modules and Akonadi starts working perfectly. As far as I can see this crash is also one of the main reasons of the notorious "nepomuk service not registered at D-bus" error which is mentioned again and again on Kubuntu and KDE forums but cannot be solved. Some translation strings (or, should I say character sets ???) not working corretly with soprano/virtuoso. Now we are getting somewhere. But I need a better backtrace. The one in this export confuses me a lot since it seems to jump back and forth. At least I cannot make much of it. Thus, I would ask you to 1. disable Nepomuk in the kcm: "kcmshell4 kcm_nepomuk" 2. make sure "nepomukserver" is running. If not start it via "nepomukserver" 3. run the storage service in gdb: "gdb --args nepomukservicestub nepomukstorage" 4. Get a backtrace from the crash that should occur and attach it here. Created attachment 49654 [details]
Nepomuk crash report (apport text file with .crash extension)
I am sorry, I am not very familiar with gdb. I failed to create a backtrace report with gdb. So I reproduced the crash with apport (ubuntu crash handler). It is a single text file with .crash extension and I hope it has all the debug information you need. I only changed the username to "username" for the sake of privacy. If it is not useful, I will try gdb again. @ismail: The backtrace did help a lot. I managed to find a bug in Soprano. However, it is not related to this bug report. :) At least not the initial commenter's crash. Hello Sebastian, I'm glad that the backtrace I provided helped you. By the way, Nepomukservicestub & soprana still crashes (With turkish Locale on KDE 4.5.1 Kubuntu maverick + Lucid). I have more information which might help you (I've posted the below information on Launchpad too, since I couldn't decide if this is KDE or Kubuntu specific problem) I have found out that this crash happens when the global LC_CTYPE variable is set to "tr_TR.utf8". I will also report this to KDE bugs. However, this bug may be Kubuntu specific. It is clear that nepomuk/soprano does not like tr_TR.utf8 charset. Nepomuk/Strigi/Akonadi runs fine with the below locale settings (this is the workaround I use): LANG=tr_TR.utf8 LANGUAGE=tr_TR LC_CTYPE=en_GB.utf8 LC_NUMERIC="tr_TR.utf8" LC_TIME="tr_TR.utf8" LC_COLLATE="tr_TR.utf8" LC_MONETARY="tr_TR.utf8" LC_MESSAGES="tr_TR.utf8" LC_PAPER="tr_TR.utf8" LC_NAME="tr_TR.utf8" LC_ADDRESS="tr_TR.utf8" LC_TELEPHONE="tr_TR.utf8" LC_MEASUREMENT="tr_TR.utf8" LC_IDENTIFICATION="tr_TR.utf8" LC_ALL= If LC_CTYPE is set to "tr_TR.utf8" then soprano crashes (On KDE 4.4+ Lucid) and also Dolphin won't open (on KDE 4.5.1 Maverick). So this is definitely a character set/soprano related problem *** Bug 285597 has been marked as a duplicate of this bug. *** This is the console output running manually nepomukservicestub nepomukstorage Using Virtuoso Version: "6.1.3.3127-pthreads" Using Virtuoso Version: "6.1.3.3127-pthreads" void Soprano::VirtuosoController::writeConfigFile(const QString&, const BackendSettings&) "/tmp/virtuoso_C29840.ini" (LockFile) could not set lock for "/home/jtorres/.kde4/share/apps/nepomuk/repository/main/data/virtuosobackend/soprano-virtuoso.db" Shutting down Virtuoso instance (29768) which is in our way. (LockFile) could not set lock for "/home/jtorres/.kde4/share/apps/nepomuk/repository/main/data/virtuosobackend/soprano-virtuoso.db" (LockFile) could not set lock for "/home/jtorres/.kde4/share/apps/nepomuk/repository/main/data/virtuosobackend/soprano-virtuoso.db" Starting Virtuoso server: "/usr/bin/virtuoso-t" ("+foreground", "+configfile", "/tmp/virtuoso_C29840.ini", "+wait") " " " Thu Nov 03 2011 " "20:25:03 OpenLink Virtuoso Universal Server " "20:25:03 Version 06.01.3127-pthreads for Linux as of ??? ?? ???? " "20:25:03 uses parts of OpenSSL, PCRE, Html Tidy " "20:25:03 Database version 3126 " "20:25:03 Entering Lite Mode " "20:25:03 SQL Optimizer enabled (max 1000 layouts) " "20:25:04 Compiler unit is timed at 0.000654 msec " "20:25:06 Roll forward started " "20:25:06 Roll forward complete " "20:25:07 Checkpoint started " "20:25:07 Checkpoint finished, log reused " "20:25:07 Server online at 1113 (pid 29859) " Virtuoso started: 29859 Soprano::ODBC::ConnectionPool::ConnectionPool(const QString&, const QStringList&, QObject*) "host=localhost:1113;uid=dba;pwd=dba;driver=/usr/lib64/virtodbc_r.so" Soprano::ODBC::Connection::Connection() QThread(0x7f6b3a8341d0) "/opt/kde4/bin/nepomukservicestub(29840)" Soprano: "SQLGetData for data length failed (iODBC Error: [OpenLink][Virtuoso iODBC Driver]CL056: Bookmarks not enable for statement)" bool Soprano::Virtuoso::DatabaseConfigurator::updateFulltextIndexRules(bool) empty rule name! virtual Soprano::ODBC::Connection::~Connection() QThread(0x7f6b3a8341d0) Soprano::ODBC::Connection::Connection() QThread(0x7f6b3a8341d0) Soprano::ODBC::Connection::Connection() Nepomuk::GraphMaintainer(0x7f6b2d4df120) And run under gdb, the stacktrace #0 0x00007ffff433d014 in __strncmp_sse2 () from /lib64/libc.so.6 #1 0x00007fffe277099d in Soprano::ODBC::QueryResult::getData (this=0x7fffe14df380, colNum=1) at /g/kdegit/kdesupport/soprano/backends/virtuoso/odbcqueryresult.cpp:158 #2 0x00007fffe27680b7 in Soprano::Virtuoso::QueryResultIteratorBackend::binding (this= 0x7fffe14df360, offset=0) at /g/kdegit/kdesupport/soprano/backends/virtuoso/virtuosoqueryresultiteratorbackend.cpp:197 #3 0x00007fffe2767d84 in Soprano::Virtuoso::QueryResultIteratorBackend::next (this= 0x7fffe14df360) at /g/kdegit/kdesupport/soprano/backends/virtuoso/virtuosoqueryresultiteratorbackend.cpp:146 #4 0x00007fffe6eb8f88 in Soprano::Iterator<Soprano::BindingSet>::next (this=0x7fffffffb570) at /opt/kde4/include/Soprano/../soprano/iterator.h:239 #5 0x00007fffe6ebe01b in CrappyInferencer2::updateInferenceIndex (this=0x7fffe145d340) at /g/kdegit/kde-runtime/nepomuk/services/storage/crappyinferencer2.cpp:476 #6 0x00007fffe6ebe6c0 in CrappyInferencer2::CrappyInferencer2 (this=0x7fffe145d340, tree= 0x7fffeebe6c10, parent=0x7fffe145d2c0) at /g/kdegit/kde-runtime/nepomuk/services/storage/crappyinferencer2.cpp:245 #7 0x00007fffe6eb11a6 in Nepomuk::Repository::open (this=0x7fffeebcfec0) at /g/kdegit/kde-runtime/nepomuk/services/storage/repository.cpp:213 #8 0x00007fffe6eb1ce4 in Nepomuk::Repository::qt_metacall (this=0x7fffeebcfec0, _c= QMetaObject::InvokeMetaMethod, _id=<optimized out>, _a=0x7fffee806f48) at /g/b45/kde-runtime/nepomuk/services/storage/repository.moc:85 #9 0x00007ffff7837ddc in QMetaObject::metacall (object=0x7fffeebcfec0, cl= QMetaObject::InvokeMetaMethod, idx=13, argv=0x7fffee806f48) at /g/kdegit/qt/src/corelib/kernel/qmetaobject.cpp:237 #10 0x00007ffff7847272 in QMetaCallEvent::placeMetaCall (this=0x7fffeeb86500, object= 0x7fffeebcfec0) at /g/kdegit/qt/src/corelib/kernel/qobject.cpp:535 #11 0x00007ffff7848534 in QObject::event (this=0x7fffeebcfec0, e=0x7fffeeb86500) at /g/kdegit/qt/src/corelib/kernel/qobject.cpp:1217 #12 0x00007ffff52a4dfe in QApplicationPrivate::notify_helper (this=0x7fffee86b380, receiver= 0x7fffeebcfec0, e=0x7fffeeb86500) at /g/kdegit/qt/src/gui/kernel/qapplication.cpp:4481 #13 0x00007ffff52a2444 in QApplication::notify (this=0x7fffffffcf10, receiver=0x7fffeebcfec0, e=0x7fffeeb86500) at /g/kdegit/qt/src/gui/kernel/qapplication.cpp:3881 #14 0x00007ffff6851cce in KApplication::notify (this=0x7fffffffcf10, receiver=0x7fffeebcfec0, event=0x7fffeeb86500) at /g/kdegit/kdelibs/kdeui/kernel/kapplication.cpp:311 #15 0x00007ffff782fd62 in QCoreApplication::notifyInternal (this=0x7fffffffcf10, receiver= 0x7fffeebcfec0, event=0x7fffeeb86500) at /g/kdegit/qt/src/corelib/kernel/qcoreapplication.cpp:787 under valgrind there is no core dump, only warnings about uninitialized variables. more information from my crash: It only happened to me with jemalloc used as malloc library (LD_PRELOAD). Otherwise, no crash at all. I've changed to jemalloc development, and the crash has gone. (In reply to comment #12) > more information from my crash: > It only happened to me with jemalloc used as malloc library (LD_PRELOAD). > Otherwise, no crash at all. > I've changed to jemalloc development, and the crash has gone. So this is not actually a bug in Nepomuk at all and this report can be closed as UPSTREAM? Please wait.... It took two days working right, but finally it crashed at the same point. An slighly different crash place, with an unusual pointer 0x100000000 #10 0x00007ff77684a7df in QScopedPointerArrayDeleter<unsigned char>::cleanup (pointer=0x100000000 "@\"\200") at /usr/lib/qt4.5/include/QtCore/qscopedpointer.h:77 #11 0x00007ff77684a3ab in QScopedPointer<unsigned char, QScopedPointerArrayDeleter<unsigned char> >::~QScopedPointer (this=0x7ff775dd1210, __in_chrg=<optimized out>) at /usr/lib/qt4.5/include/QtCore/qscopedpointer.h:100 #12 0x00007ff77684976e in Soprano::ODBC::QueryResult::getData (this=0x352304e0, colNum=1) at /g/kdegit/kdesupport/soprano/backends/virtuoso/odbcqueryresult.cpp:120 Ping? Does this crash still occur or can I close it as UPSTREAM? I've not seen this error (reading a long int from the database) for some time. You can close if nobody else complains. Yaye! Closing :) |