Bug 1147121
| Summary: | Evolution and Firefox become unresponsive when application is opened for user input. | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kristjan Stefansson <hk.stefansson> | ||||||||
| Component: | evolution | Assignee: | Milan Crha <mcrha> | ||||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 20 | CC: | hk.stefansson, kartochka378, lucilanga, mbarnes, mcrha, tpopela | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2014-12-01 07:26:09 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: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Kristjan Stefansson
2014-09-27 03:50:06 UTC
Thanks for a bug report. It looks pretty odd to see both Evolution and Firefox stuck. The only common part is using NSS for networking, and then maybe some UI libraries (like gtk+, though even that can be of a different version). Could you install debug info package for your evolution, reproduce the issue and catch a backtrace of runnig evolution, to see where it got stuck, please? You can get the backtrace with command like this: $ gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txt Please check the bt.txt for any private information, like passwords, email address, server addresses,... I usually search for "pass" at least (quotes for clarity only). Hi thank you for the response, I installed the debug info but was not able to repreduce the problem with Evoution as the program was responsive and fetces all the mail. I will have my father tell me if he has any problems and then I'm ready with the backtrace. Thanks. I'm moving this back to need-info, just that I know this is not waiting on me. Created attachment 962591 [details]
backrtace
Attachment is requested backtrace. I have few evilution hangs, not a lot but like 1 hung from 5-7 attempts to accessing my yandex mail account using imap, both on F20 few month ago, and on freshly updated F21. The fun is my gnome terminal hungs just after i use that command (gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txt), it complete, cursor jump on next line as it expected, blinking, but any kb activity (even ctrl-q, esc, etc) just ignored. New terminal work fine. Very suspisious.
Created attachment 962592 [details]
screenshot of evolution hang
This is how it looks, after trying to exit (right top close button pressed). It stay in that state untill box reboot, no other attepmts to kill application works.
Created attachment 962593 [details]
another hung
For reproduce i just close and open evolution client 3 times. First 2 times it open my mail almost instant. Last was it stuck but looks like usual network or server problem, just long waiting for connect. Menu navigation, other folder selection work fine. Actual hang happens only after i try to close application using hight top cross button.
I see similar backtrace, just pid number differ, no idea is is useful to post more.
Thanks for the update. I see what it does. The Evolution is not unresponsive as such, when you asked it to quit, it disabled its content and started the quit phase. The Evolution doesn't quit if there is any ongoing activity (these are usually shown in the status bar). There is one "ongoing" activity, the Evolution tries to connect to your server. That's also what the backtrace shows. The backtrace also shows that there is missing a corresponding imapx parser thread, where is done all the communication between the server and the client. This all together means that you are facing bug #1148293, thus I mark this as a duplicate of it. *** This bug has been marked as a duplicate of bug 1148293 *** |