Bug 328780 - KMail2 stops responding in Nepomuk2::MainModel::executeQuery
Summary: KMail2 stops responding in Nepomuk2::MainModel::executeQuery
Status: RESOLVED UNMAINTAINED
Alias: None
Product: nepomuk
Classification: Miscellaneous
Component: libnepomukcore (show other bugs)
Version: 4.11.3
Platform: openSUSE Linux
: NOR crash
Target Milestone: ---
Assignee: Nepomuk Bugs Coordination
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-14 01:16 UTC by Christopher Yeleighton
Modified: 2015-01-23 16:18 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Yeleighton 2013-12-14 01:16:32 UTC
It seems that Nepomuk2::MainModel::executeQuery is a blocking IPC call issued in the GUI thread.

Reproducible: Sometimes

Steps to Reproduce:
  1. Hover over an IMAP message.

Actual Results:  
  1. 
Kontact stops responding (it seems that Nepomuk2::MainModel::executeQuery is a blocking IPC call issued in the GUI thread), virtuoso-t eats 90% CPU.

Expected Results:  
  1. Let Kontact display message summary.

I surely do not know why virtuoso-t runs forever or how to stop it or whether stopping it will unfreeze KMail2; it seems that KMail2 should take this possibility into account.

Backtrace (reduced):

#0  0x00007f352c8f8913 in select () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f34b5283c31 in tcpses_is_read_ready (ses=0x2243690, 
    to=to@entry=0x2e6d834) at Dksestcp.c:1055
#2  0x00007f34b52889a1 in PrpcFutureNextResult1T (future=0x2e6d800)
    at Dkernel.c:4251
#3  PrpcFutureNextResult (future=0x2e6d800) at Dkernel.c:4084
#4  0x00007f34b5254e8d in stmt_process_result (stmt=stmt@entry=0x2e6daf0, 
    needs_evl=needs_evl@entry=1) at ../../libsrc/Wi/CLIuti.c:719
#5  0x00007f34b52551e2 in stmt_process_result (stmt=stmt@entry=0x2e6daf0, 
    needs_evl=needs_evl@entry=1) at ../../libsrc/Wi/CLIuti.c:885
#6  0x00007f34b5258ef5 in virtodbc__SQLExecDirect (hstmt=0x2e6daf0, 
    szSqlStr=<optimized out>, cbSqlStr=<optimized out>)
    at ../../libsrc/Wi/CLIsql1.c:1530
#7  0x00007f34b55c39e4 in SQLExecDirect_Internal (hstmt=hstmt@entry=0x2f01070, 
    szSqlStr=szSqlStr@entry=0x2e76918, cbSqlStr=cbSqlStr@entry=258, 
    waMode=waMode@entry=65 'A') at execute.c:549
#8  0x00007f34b55c3d14 in SQLExecDirect (hstmt=0x2f01070, 
    szSqlStr=0x2e76918 "sparql DEFINE input:inference <nepomukinference> select distinct ?r ?o where { { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#url> <akonadi:?item=25205> . FILTER(?r!=<akonadi:?item=252"..., 
    cbSqlStr=258) at execute.c:631
#9  0x00007f34b581fd29 in Soprano::ODBC::Connection::execute (this=this@entry=
    0x2a05250, request=..., params=...)
    at /usr/src/debug/soprano-2.9.4/backends/virtuoso/odbcconnection.cpp:158
#10 0x00007f34b58208f1 in Soprano::ODBC::Connection::executeQuery (
    this=this@entry=0x2a05250, request=...)
    at /usr/src/debug/soprano-2.9.4/backends/virtuoso/odbcconnection.cpp:89
#11 0x00007f34b580ca35 in sqlQuery (query=..., this=0x2a04dc0)
    at /usr/src/debug/soprano-2.9.4/backends/virtuoso/virtuosomodel.cpp:128
#12 Soprano::VirtuosoModelPrivate::sparqlQuery (this=0x2a04dc0, query=...)
    at /usr/src/debug/soprano-2.9.4/backends/virtuoso/virtuosomodel.cpp:148
#13 0x00007f34b580ccd8 in Soprano::VirtuosoModel::executeQuery (
    this=this@entry=0x2e6c640, query=..., 
    language=language@entry=Soprano::Query::QueryLanguageSparql, 
    userQueryLanguage=...)
    at /usr/src/debug/soprano-2.9.4/backends/virtuoso/virtuosomodel.cpp:485
14 0x00007f35223e8d33 in Nepomuk2::MainModel::executeQuery (this=0x1fee370, 
    query=..., language=<optimized out>, userQueryLanguage=...)
    at /usr/src/debug/nepomuk-core-4.11.3/libnepomukcore/resource/nepomukmainmodel.cpp:191
#15 0x00007f35223df17d in Nepomuk2::ResourceData::determineUri (
    this=this@entry=0x2e0cdc0)
    at /usr/src/debug/nepomuk-core-4.11.3/libnepomukcore/resource/resourcedata.cpp:638
#16 0x00007f35223e9d60 in Nepomuk2::Resource::determineFinalResourceData (
    this=0x7fff44befdb0)
    at /usr/src/debug/nepomuk-core-4.11.3/libnepomukcore/resource/resource.cpp:760
#17 0x00007f35223ea005 in Nepomuk2::Resource::property (this=0x7fff44befdb0, 
    uri=...)
    at /usr/src/debug/nepomuk-core-4.11.3/libnepomukcore/resource/resource.cpp:266
#18 0x00007f34c81bb82d in MessageList::Util::contentSummary(KUrl const&) ()
   from /usr/lib64/libmessagelist.so.4
#19 0x00007f34c8193127 in MessageList::Core::View::event(QEvent*) ()
   from /usr/lib64/libmessagelist.so.4
Comment 1 Christopher Yeleighton 2013-12-14 01:51:44 UTC
KMail2 eventually recovered, I am not sure whether because I used isql-vt to inquire the status of virtuoso server or because virtuoso recovered by itself.  However, the bug is still valid because the assumption that virtuoso will respond instantly turns out to be wrong.
Comment 2 Vishesh Handa 2015-01-23 16:18:12 UTC
Thank you for taking the time to file a bug report.

The Nepomuk project is no longer included in the KDE Software Compilation. With Plasma 5, we have replaced most of the underlying technology with Baloo and other components. Hopefully this will have addressed your concern.

We encourage you to try out Plasma 5 (+Baloo) and let us know if your problem persists.