Bug 813266
| Summary: | Deadlock on folder search | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | David Jaša <djasa> | ||||||||
| Component: | evolution-data-server | Assignee: | Matthew Barnes <mbarnes> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | medium | ||||||||||
| Version: | 6.3 | CC: | jkoten, lnovich, mcrha, tpelka | ||||||||
| Target Milestone: | beta | ||||||||||
| Target Release: | 6.4 | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | evolution-data-server-2.32.3-2.el6 | Doc Type: | Bug Fix | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2013-11-21 05:05:08 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | 883014 | ||||||||||
| Bug Blocks: | |||||||||||
| Attachments: |
|
||||||||||
Created attachment 577998 [details]
e-d-s backtrace
Thanks for a bug report. EDS is trying to update your CalDAV calendar (probably on the same unreachable server), but it has no influence on evolution here, which is in deadlock. Thread two and thread 3 are waiting on the same mutex, while thread 4 is waiting on a different mutex. My initial guess would be that the thread 4 is waiting on a mutex which holds thread 2. I'll check the code. Created attachment 578270 [details] eds patch for evolution-data-server; Untested, but that's basically a corresponding fix for an upstream bug [1]. That bug also mentions patch for changing CamelFolderSummary locks into recursive locks, which is already part of eds 2.28.3-15 package. [1] https://bugzilla.gnome.org/show_bug.cgi?id=617261 This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux. This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development. This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4. This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux. Upstream fix is part of 2.32.3, thus I mark this as a dependency of the rebase bug. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-1540.html |
Created attachment 577997 [details] evo backtrace Description of problem: message list and message preview get stuck when searching folder in online mode on unreachable server. When hitting cancel buttons at "Generating message list" and "Formatting message", nothing happens, the only way to resume work is to force shutdown evolution (the rest of UI behaves normally however). Version-Release number of selected component (if applicable): evolution-2.28.3-25.2.el6.x86_64 How reproducible: always Steps to Reproduce: 1. disconnect network in a way that NM doesn't notice so evo stays in online mode 2. go to folder in that unreachable account 3. type something to search bar, hit enter Actual results: * message list and message preview widgets get unresponsive * cancelling "Generating message list" and "Formatting message" does nothing * changing folder/account in tree view has no effect either Expected results: * when account can not be reached, evolution falls back to search in cache * when cancel button is hit, evolution cancels all the actions * when user goes to another folder, search is cancelled, too Additional info: