| Summary: | akonadi_imap_resource eats 100% CPU | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] Akonadi | Reporter: | Lastique <andysem> |
| Component: | IMAP resource | Assignee: | Christian Mollekopf <chrigi_1> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | casta, dvratil, faure, kdepim-bugs, mollekopf, vkrause |
| Priority: | NOR | ||
| Version: | 4.10 | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | strace log fragment from the akonadi_imap_resource | ||
|
Description
Lastique
2013-04-09 17:12:01 UTC
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. |