Sometimes, akonadi_imap_resource starts to eat 100% CPU (a single thread, apparently). When that happens, the IMAP account that is served by this process becomes unresponsive in Kmail (selecting a folder and an email shows the "Retrieving folder contents" page). The only way to solve it is to kill the akonadi_imap_resource process and restart it. I don't know what triggers this behavior as I'm not doing anything special with email when that happens. There were no observable network problems, so I don't think it is related to the IMAP server connectivity. Reproducible: Sometimes
Created attachment 78754 [details] strace log fragment from the akonadi_imap_resource I saved an strace log from the offending process. It seems to loop indefinitely trying to update a folder 'Hudson' which is present in my account.
Hi, should probably be a dupe of #316541 ?
(In reply to comment #2) > Hi, should probably be a dupe of #316541 ? No, I didn't shut down Kmail, it was always running.
The bug #316541 also happen kmail opened (look at the "even" in the title). I'm pretty shure it's the same : same strace more or less, same network consumption.
(In reply to comment #4) > The bug #316541 also happen kmail opened (look at the "even" in the title). > I'm pretty shure it's the same : same strace more or less, same network > consumption. The #316541 bug description (and steps to reproduce, and comments) don't communicate that the problem is not related to Kmail shutdown, so I'd rather not mark it as a duplicate. I'm not always having this issue and frankly, I didn't notice high network consumption (although it's possible I simply missed it). But if developers are sure it's a duplicate then surely they will mark it as such and I'm ok with that.
gdb output from the resource would be more useful. Can you please try to obtain it, once this happens again?
I'll try, but it doesn't happen very often. It only happened once or twice since I filled the report.
Please enable all debug output and look at .xsession-errors when it happens. If you see a constant stream of "Cancelling this request. Probably there is no more session available." then I just fixed this bug.
Git commit a4299dbabf37e692f4355ed4871fc0e3681d765b by David Faure. Committed on 26/06/2013 at 10:13. Pushed by dfaure into branch 'KDE/4.10'. Cancel session request if the task is deleted early. E.g. due to losing the connection to the server. Otherwise the request is processed later on, with no task to use that session, and we end up with a session in m_reservedSession for ever, and soon afterwards an infinite stream of "Cancelling this request. Probably there is no more session available." Might be related to: Related: bug 316541 (but for lack of debug output in these reports, I can't tell for sure) FIXED-IN: 4.10.5 Reviewed-by: Kévin Ottens M +5 -2 resources/imap/resourcetask.cpp M +6 -0 resources/imap/sessionpool.cpp M +1 -0 resources/imap/sessionpool.h M +43 -0 resources/imap/tests/testsessionpool.cpp http://commits.kde.org/kdepim-runtime/a4299dbabf37e692f4355ed4871fc0e3681d765b
Git commit 00784dd1a92cb00069df9e5f296e02f268fab6ed by David Faure. Committed on 04/07/2013 at 21:00. Pushed by dfaure into branch 'KDE/4.10'. Cancel session request if imap idle manager is deleted before getting a session. Same logic as commit a4299dbabf37e692f4355ed4871fc0e3681d765b, but for the idle manager. Same possible symptom later on, an infinite number of: "Cancelling this request. Probably there is no more session available." Related: bug 316541 FIXED-IN: 4.11 CCMAIL: ervin@kde.org M +7 -2 resources/imap/imapidlemanager.cpp http://commits.kde.org/kdepim-runtime/00784dd1a92cb00069df9e5f296e02f268fab6ed
The IMAP resource has a new maintainer, reassigning to him.
I'll close this for now, please reopen if it still applies.