[Kde-pim] Threading Issue in Akonadi

[Andreas Cord-Landwehr]

Dear all,

this weekend I spent digging into a strange Akonadi problem (happens with 
Akonadi master, as well as 1.8 RC). The problem is invoked from KMail but 
afais it lies in nepomuksearch.cpp. Details follow:

Introduction:
In KMail I have a couple of mails that when I click on them (i.e. to display) 
I get the "Retrieving Folder Contents" bluescreen. With GDB I followed the 
problem into the Akonadi sources: When trying to display the mail at some 
point an Akonadi Connection is created as well as AkonadiConnection::run() is 
exucuted, which yields (after some more calls) to search.cpp:55 where a 
NepomukSearch object is created and (one line later) a search is executed.
The following I give in detail to explain how there a threading issues emerges 
from the calls (especially here in case of a specific mail I try to display):

Step 1. Object creation of "NepomukSearch* service" in search.cpp:55
This causes the NepomukSearch ctor to create:
  mSearchService = new Nepomuk::Query::QueryServiceClient( this );
  mIdSearchService = new Nepomuk::Query::QueryServiceClient( this );
Futher in the ctor, for both there newEntries-signals are connected to methods 
of NepomukSearch, ie.
  connect( mSearchService, SIGNAL(newEntries(QList<Nepomuk::Query::Result>)),
           this, SLOT(hitsAdded(QList<Nepomuk::Query::Result>)) );
  mIdSearchService = new Nepomuk::Query::QueryServiceClient( this );
  connect( mIdSearchService, 
SIGNAL(newEntries(QList<Nepomuk::Query::Result>)),
           this, SLOT(idHitsAdded(QList<Nepomuk::Query::Result>)) );

Step 2. search:cpp:56 service->search(...) is called. There we get:
* mSearchService->blockingQuery(...) issues a query
* this query finds 6 results (in my example)
* by former connection of mSearchService, for each result 
NepomukSearch::hitsAdded is invoked
* FOR-EVERY-OF-THESE-RESULTS it happens in NepomukSearch::hitsAdded(...)
  * the result has akonadi ID => mIdSearchService->blockingQuery(...) is 
invoked
* THE-LAST-INVOKED-QUERY finishs and invokes by the, in the ctor created, 
connection NepomukSearch::idHitsAdded(...)
  * uses addHit(...) to add result to result-list
  * then idHitsAdded(...) returns
  * the blockingQuery THE-LAST-INVOKED-QUERY returns from the call from 
QueryServiceClient::blockingQuery
<<< AKONADI STALLS >>>

Conclusion:
I verfied that virtuoso finished all queries as well as that none of the other 
blockingQuery calls returned. (Akonadi is Git master, KDEPIM/KDEPIMlibs is KDE 
4.9 RC2.)
I suspect that by return from the blockingQuery the still blocking thread is 
invoked. Hence, the next blockingQuery issued by mSearchService can never 
return.

I would be happy about any comments/fixes/remarks. Currently I am not sure 
about how to approach a fix for this problem. I can trigger the problem 
deterministicly.

Greetings,
   Andreas
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/