nepomukservicestub crashed with SIGSEGV in Soprano::ODBC::Connection::execute()

Bug #541856 reported by Ersin Akyüz
38
This bug affects 5 people
Affects Status Importance Assigned to Milestone
KDE Base
Won't Fix
High
kdebase-runtime (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

Binary package hint: kdebase-runtime

Crashed after logged in to KDE (Kubuntu package loaded to Ubuntu)

ProblemType: Crash
Architecture: i386
Date: Fri Mar 19 14:22:27 2010
DistroRelease: Ubuntu 10.04
ExecutablePath: /usr/bin/nepomukservicestub
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha i386 (20100224.1)
Package: kdebase-runtime 4:4.4.1-0ubuntu3
ProcCmdline: /usr/bin/nepomukservicestub nepomukstorage
ProcEnviron:
 LANG=tr_TR.utf8
 SHELL=/bin/bash
 LANGUAGE=
ProcVersionSignature: Ubuntu 2.6.32-16.25-generic
SegvAnalysis:
 Segfault happened at: 0x9a330f1 <_ZN7Soprano4ODBC10Connection7executeERK7QString+33>: mov 0x10(%esi),%eax
 PC (0x09a330f1) ok
 source "0x10(%esi)" (0x00000010) not located in a known VMA region (needed readable region)!
 destination "%eax" ok
SegvReason: reading NULL VMA
Signal: 11
SourcePackage: kdebase-runtime
StacktraceTop:
 Soprano::ODBC::Connection::execute(QString const&) ()
 Soprano::ODBC::Connection::executeQuery(QString const&) ()
 Soprano::Virtuoso::DatabaseConfigurator::updateFulltextIndexRules(bool) () from /usr/lib/soprano/libsoprano_virtuosobackend.so
 Soprano::Virtuoso::DatabaseConfigurator::updateFulltextIndexState(QString const&) () from /usr/lib/soprano/libsoprano_virtuosobackend.so
 Soprano::Virtuoso::DatabaseConfigurator::configureServer(QList<Soprano::BackendSetting> const&) ()
Title: nepomukservicestub crashed with SIGSEGV in Soprano::ODBC::Connection::execute()
Uname: Linux 2.6.32-16-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
XsessionErrors: (process:6091): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

Revision history for this message
Ersin Akyüz (ersinakyuz) wrote :
Revision history for this message
Apport retracing service (apport) wrote :

StacktraceTop:
 Soprano::ODBC::QueryResult::getData (this=0xbfce5848,
 Soprano::ODBC::QueryResult::getData (this=0xbfce5848,
 ~ConnectionPool (this=0xbfce5a38)
 Soprano::ODBC::QueryResult::resultColumns (this=0x1)
 Soprano::ODBC::QueryResult::getCharData (this=0x1,

Revision history for this message
Apport retracing service (apport) wrote : Stacktrace.txt
Revision history for this message
Apport retracing service (apport) wrote : ThreadStacktrace.txt
Changed in kdebase-runtime (Ubuntu):
importance: Undecided → Medium
tags: removed: need-i386-retrace
visibility: private → public
Changed in kdebase-runtime (Ubuntu):
status: New → Triaged
Changed in kdebase:
status: Unknown → Confirmed
Revision history for this message
In , Jonathan Thomas (echidnaman) wrote :
Download full text (13.8 KiB)

Version: (using KDE 4.4.1)
Installed from: Ubuntu Packages

Originally reported at https://launchpad.net/bugs/541856

The crash occurred at either startup or shutdown, I cannot determine which from the stacktrace. The user reported that the crash occurred at startup, but this is also when crashes on shutdown are reported by apport.

.
Thread 2 (process 6118):
#0 0x0084d422 in __kernel_vsyscall ()
No symbol table info available.
#1 0x059c38f1 in fchflags (fd=5077136, flags=0) at fchflags.c:31
No locals.
#2 0x002c032e in QThreadPrivate::start (arg=0x0)
    at thread/qthread_unix.cpp:248
 data = (QThreadData *) 0x0
#3 0x008d496e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
No symbol table info available.
#4 0x059ca92e in _L_unlock_158 () from /lib/tls/i686/cmov/libc.so.6
No locals.
#5 0x059ca83e in __fgetspent_r (stream=Cannot access memory at address 0x8
) at fgetspent_r.c:75
 ignore = <value optimized out>
 p = <value optimized out>
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
.
Thread 1 (process 6112):
#0 0x09a330f1 in Soprano::ODBC::QueryResult::getData (this=0xbfce5848,
    colNum=5) at ../../../backends/virtuoso/odbcqueryresult.cpp:217
 langBuf = "�\0351\000\030\000\000\000�000\000\000��\005\020Y�\thZ�HW����7b\000\236\235�\t\005\000\000\000PW�a\000 \\�\000\000\000\000\001\000\000\000\005\000\000\000\000\000\000\000\005\000\000\000��\tX\025\003\000\000 �\t\020Y�\t�t\000\000\000"
 typeBuf = "\001\000\000\000hZ�hZ��e�\t��\t�\t\001\000\000\000�7b\000\220Wο\000\000\000\000@Wο�004Wο�\thZ�\000\000\000\000\000\000\000\000\236\235�\t�\t\000\000\000\000\001\000\000\000LWο\026\214?\000\b�005J\000\000"
 langBufLen = 0
 typeBufLen = 276063565
 type = {d = 0xbfce5695}
 lang = {static null = {<No data fields>}, static shared_null = {
    ref = {_q_value = 2711}, alloc = 0, size = 0, data = 0x4d747a, clean = 0,
    simpletext = 0, righttoleft = 0, asciiCache = 0, capacity = 0,
    reserved = 0, array = {0}}, static shared_empty = {ref = {_q_value = 44},
    alloc = 0, size = 0, data = 0x4d748e, clean = 0, simpletext = 0,
    righttoleft = 0, asciiCache = 0, capacity = 0, reserved = 0, array = {
      0}}, d = 0x615a26, static codecForCStrings = 0x0}
 str = 0x59698a6 "]�213E\f\211U�1M�114$\211D$\004��3M�13U�1�?���\215�"
 hdesc = (SQLHDESC) 0x9e35bc4
 dvtype = -1076996360
 node = {d = {d = 0x6162e0}}
 data = (SQLCHAR *) 0x0
 length = 0
#1 0x09a334bc in Soprano::ODBC::QueryResult::getData (this=0xbfce5848,
    colNum=161585406) at ../../../backends/virtuoso/odbcqueryresult.cpp:118
 hdesc = (SQLHDESC) 0x0
 dvtype = 165894760
 node = {d = {d = 0xbfce56f8}}
 data = (SQLCHAR *) 0x9a19d9e "�\201�R\002"
 length = 0
#2 0x09a31500 in ~ConnectionPool (this=0xbfce5a38)
    at /usr/include/qt4/QtCore/qhash.h:584
No locals.
#3 0x09a31e4f in Soprano::ODBC::QueryResult::resultColumns (this=0x1)
    at /usr/include/qt4/QtCore/qatomic_i386.h:120
No locals.
#4 0x09a32274 in Soprano::ODBC::QueryResult::getCharData (this=0x1,
    colNum=<value optimized out>, buffer=0x0, length=0x4)
    at ../../../bac...

Revision history for this message
Jonathan Thomas (echidnaman) wrote :

Can this crash still be reproduced?

Changed in kdebase-runtime (Ubuntu):
status: Triaged → Incomplete
Revision history for this message
In , Trueg (trueg) wrote :

Can this crash still be reproduced?

Revision history for this message
In , Jonathan Thomas (echidnaman) wrote :

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.

Revision history for this message
İsmail YILMAZ (ismailyilmaz1978) wrote :

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.

Revision history for this message
Jonathan Thomas (echidnaman) wrote :

Thanks for the response. It would be great if you could also follow the upstream bug here: http://bugs.kde.org/show_bug.cgi?id=232760 , as the nepomuk developer may need to talk with you for details of the crash, and direct communication is more effective than me relaying it between you two. ;)

Thanks in advance.

Changed in kdebase-runtime (Ubuntu):
status: Incomplete → Triaged
Revision history for this message
In , Jonathan Thomas (echidnaman) wrote :

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."

Revision history for this message
İsmail YILMAZ (ismailyilmaz1978) wrote :

Ok, I'll give a description of this bug on KDE bug tracking system, asap.
Thanks.

Revision history for this message
In , İsmail YILMAZ (ismailyilmaz1978) wrote :

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.

Revision history for this message
In , Trueg (trueg) wrote :

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.

Revision history for this message
In , İsmail YILMAZ (ismailyilmaz1978) wrote :

Created attachment 49654
Nepomuk crash report (apport text file with .crash extension)

Revision history for this message
In , İsmail YILMAZ (ismailyilmaz1978) wrote :

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.

Revision history for this message
In , Trueg (trueg) wrote :

@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.

Revision history for this message
İsmail YILMAZ (ismailyilmaz1978) wrote :

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

Revision history for this message
In , İsmail YILMAZ (ismailyilmaz1978) wrote :

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

Changed in kdebase:
importance: Unknown → High
Revision history for this message
In , Trueg (trueg) wrote :

*** Bug 285597 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Jtamate (jtamate) wrote :
Download full text (5.1 KiB)

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::updat...

Read more...

Revision history for this message
In , Jtamate (jtamate) wrote :

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.

Revision history for this message
In , Trueg (trueg) wrote :

(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?

Revision history for this message
In , Jtamate (jtamate) wrote :

Please wait.... It took two days working right, but finally it crashed at the same point.

Revision history for this message
In , Jtamate (jtamate) wrote :

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

Revision history for this message
In , Me-ngeefk4xayt3t4u9watah405ve (me-ngeefk4xayt3t4u9watah405ve) wrote :

Ping?

Does this crash still occur or can I close it as UPSTREAM?

Revision history for this message
In , Jtamate (jtamate) wrote :

I've not seen this error (reading a long int from the database) for some time. You can close if nobody else complains.

Revision history for this message
In , Me-ngeefk4xayt3t4u9watah405ve (me-ngeefk4xayt3t4u9watah405ve) wrote :

Yaye! Closing :)

Changed in kde-baseapps:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.