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

Bug #541856 reported by Ersin Akyuz on 2010-03-19
38
This bug affects 5 people
Affects Status Importance Assigned to Milestone
KDE Base
Won't Fix
High
kdebase-runtime (Ubuntu)
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

Ersin Akyuz (ersin2k) 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,

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

Jonathan Thomas (echidnaman) wrote :

Can this crash still be reproduced?

Changed in kdebase-runtime (Ubuntu):
status: Triaged → Incomplete

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.

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.

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

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

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

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

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

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

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

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

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.

Changed in kde-baseapps:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
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.