[kmail2] [Bug 323929] kmail high cpu load, seems stuck looping on fetching mails from akonadi

[Christian Mollekopf]

https://bugs.kde.org/show_bug.cgi?id=323929

--- Comment #34 from Christian Mollekopf <mollekopf at kolabsys.com> ---
I'm not sure the applied fix actually fixed the actual problem, since the use
of Qt::UniqueConnection was IMO just fine. The applied patch just disconnects 
slotDefaultCollectionsChanged, which it probably shouldn't as we want to get
updates for changed default collections. It of course works around the problem
of the loop, but probably introduces a new bug.

Here's the analysis from thiago from 323068:
1) when KMail starts, I suppose MailCommon::Kernel::initFolders is called to
initialise the folder listing
2) MailCommon::Kernel::initFolders creates a
Akonadi::SpecialMailCollectionsDiscoveryJob job (derived from
Akonadi::SpecialCollectionsDiscoveryJob)
3) when Akonadi::SpecialCollectionsDiscoveryJob finishes,
Akonadi::SpecialCollectionsDiscoveryJob::slotResult is called
4) Akonadi::SpecialCollectionsDiscoveryJob::slotResult iterates over the result
(201 folders). For two folders, it calls:
68                 
d->mSpecialCollections->registerCollection(collection.attribute<SpecialCollectionAttribute>()->collectionType(),
collection);
  The two folders have mRemoteId = "outbox" and mRemoteId = "caixa de saída"
(don't ask me why one is localised and the other isn't).
5) because of those calls, Akonadi::SpecialCollectionsPrivate::emitChanged gets
called
6) since those two folders have resourceId == mDefaultResourceId, the
defaultCollectionsChanged() signal gets called, which ends up calling
MailCommon::Kernel::initFolders
7) repeat ad nauseam

-- 
You are receiving this mail because:
You are the assignee for the bug.