Long delay before new/compose window appears
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evolution |
Invalid
|
Undecided
|
Unassigned | ||
GtkHTML |
Invalid
|
Undecided
|
Unassigned | ||
gtk+2.0 (Ubuntu) |
Fix Released
|
Low
|
Ubuntu Desktop Bugs |
Bug Description
On my remote X11 clients, Evolution takes 20 - 30 seconds to display the compose / reply window. This happens on all clients, including a PXE-booted KVM virtual machine and a Xephyr X server. The problem occurs whether the X11 connection is ssh-tunneled or is a direct connection in the clear (using XDMCP).
Performance is otherwise normal, in Evolution and elsewhere.
Tracker has been removed. libtrackerclient is still installed as it's required by Totem, but Evolution does not link to it according to `ldd'.
IPv6 has been disabled, as previous bug reports have indicated that IPv6 may be the issue. `ip -6 r s' shows no routes, there are no inet6 addresses in `ip addr show', and the disable_ipv6 flag has been set in sysctl for all system interfaces.
Probably related bugs: bug #366101, bug #159153 . I've filed this separately because of the involvement of networked sessions. (though, as I haven't been able to test a physical console yet, there's no guarantee it's network only).
I'll attach a trace of the X11 traffic taken while Evolution is opening the compose window after clicking on the "new" button in the toolbar.
System details:
-------
$ lsb_release -rd
Description: Ubuntu 9.04
Release: 9.04
evolution:
Installed: 2.26.1-0ubuntu2
tracker:
Installed: (none)
evolution-
Installed: 2.26.1-0ubuntu2
-------
Related branches
Changed in evolution: | |
status: | Unknown → New |
Changed in gtkhtml: | |
status: | Unknown → New |
Changed in evolution (Ubuntu): | |
status: | New → Triaged |
affects: | evolution (Ubuntu) → gtk+2.0 (Ubuntu) |
Changed in gtk+2.0 (Ubuntu): | |
status: | In Progress → Fix Committed |
Changed in libgtk: | |
status: | Unknown → Fix Released |
Changed in libgtk: | |
importance: | Unknown → Medium |
To examine the libpcap trace, open it with Wireshark, right-click on the first packet, and choose "Decode as". In the window that appears select the "Transport" tab, then the "X11" protocol in the list. Hit apply, then close.
You'll now see the decoded X11 traffic. (Note that this traffic is for the WHOLE SERVER, not just Evolution).
It's also informative to use the I/O graph. From the main menu, hit Statistics->I/O graphs. The first hump is moving the pointer to the "new" button and clicking on it, then moving the pointer out of the Xephyr window to wait for the compose window to appear. There's then a long period of steady low-rate traffic corresponding to the period when Evolution is non-responsive (from around seconds 6-18 in this particular trace), followed by a spike as it sets up and draws the window.
(I've attached a PNG of the graph, but if you actually fire up Wireshark and generate it yourself you'll be able to click on parts of it to move the main window's selection to that part of the timeline.)
The long flat period, when examined, appears to be a continuous loop of the following X11 operations:
(C: X11 client; S: X11 server):
C->S: Requests: Grabserver, QueryPointer
S->C: Reply: QueryPointer
C->S: Requests: QueryPointer
S->C: Reply: QueryPointer
C->S: UngrabServer
There are over 400 such repetitions in the particular sample I'm examining right now. Most are looping one after the other, but some are intermixed with other operations before or after the long slow period. However, at this point I'm not 100% sure they're even from Evolution.