Bug 818101 - Evolution becomes unresponsive after requesting message composition window (NFS home directories)
Evolution becomes unresponsive after requesting message composition window (N...
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: evolution (Show other bugs)
17
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Matthew Barnes
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-02 04:43 EDT by Braden McDaniel
Modified: 2012-05-04 02:28 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-04 01:01:40 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Braden McDaniel 2012-05-02 04:43:20 EDT
Description of problem:
I am using an NFSv4-mounted home directory. When requesting the message composition window, Evolution immediately becomes completely unresponsive (and must be killed).

When I look at the process status in GNOME System Monitor, "Waiting Channel" alternates between "nfs_wait_bit_killable" and "rpc_wait_bit_killable".

Version-Release number of selected component (if applicable):
3.4.1-2.fc17

How reproducible:
Consistently.
Comment 1 Milan Crha 2012-05-03 02:46:07 EDT
Thanks for a bug report. If I got it right then this happens either when you compose a new message or reply to one, am I right? It would be strange if it's dependant on the NFS, but who knows. Could you get a backtrace of running evolution, to see where exactly it's stuck, please? Please make sure you have installed debuginfo packages at least for gtkhtml3, evolution-data-server and evolution, and that they are of the same version as the binary packages (thus debug symbols will match and backtrace will be usable). Then let evolution freeze and get backtrace with command like this:
   $ gdb --batch --ex "t a a bt" -pid=PID &>bt.txt
where PID is a process ID of the running evolution. Please examine the bt.txt first, and if it'll contain any claim on ptrace policy, then follow instructions from there and get the backtrace again. Also make sure the resulting file will not contain any private information, like passwords or server addresses (I usually search for "pass" (quotes for clarity only)). Then attach the bt.txt file here, please. Thanks in advance.
Comment 2 Braden McDaniel 2012-05-03 03:27:37 EDT
(In reply to comment #1)
> If I got it right then this happens either when you
> compose a new message or reply to one, am I right?

Yes.

> It would be strange if it's
> dependant on the NFS, but who knows. Could you get a backtrace of running
> evolution, to see where exactly it's stuck, please? Please make sure you have
> installed debuginfo packages at least for gtkhtml3, evolution-data-server and
> evolution, and that they are of the same version as the binary packages (thus
> debug symbols will match and backtrace will be usable). Then let evolution
> freeze and get backtrace with command like this:
>    $ gdb --batch --ex "t a a bt" -pid=PID &>bt.txt

This does not return; it appears just to wait.

Similarly, if I try to attach to the process using gdb interactively, I cannot seem to get a gdb prompt once Evolution becomes unresponsive. Ctrl-C is not effective.
Comment 3 Braden McDaniel 2012-05-04 01:01:40 EDT
With the most recent updates from updates-testing, I can no longer reproduce this. Those updates included kernel 3.3.4-3; so possibly Evolution was tripping over a kernel bug here.

(I didn't see any other packages in this round of updates that might possibly have affected this.)
Comment 4 Milan Crha 2012-05-04 02:28:08 EDT
Thanks for the update. Than that was pretty low in the stack, it seems. Good it works for you again.

Note You need to log in before you can comment on or make changes to this bug.