GNOME Bugzilla – Bug 585624
On any TCP/IP based X session, mail edit window takes 15-40 seconds to appear after clicking compose/new/reply/forward
Last modified: 2009-06-22 03:30:34 UTC
This does not appear to be Tracker-related like bug 575821 or others I've seen. Initially reported in LaunchPad as https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/386199 . When using Evolution over a network X11 connection ("ssh -X" or direct TCP/IP using XDMCP), Evolution takes a very long time to open the mail edit window after "new", "foward" or "reply" is clicked. It occurs when Evolution is displaying on any display that requires network communication, including: - Xephyr running on my test machine, connecting to the XDMCP server on another host using "-query" and running evo in the remote session over direct TCP/IP. - A KVM virtual LTSP workstation connecting using LDM and ssh forwarding, running evo on another host over ssh X tunneling. - Real physical LTSP workstations with a variety of network cards and graphics chips, running evo over SSH X tunneling to another host. - A real `nv' or `nvidia' X server running on my workstation, connecting to the XDMCP server using "-query", running evo over direct TCP/IP on another host. - Xephyr running on my workstation, connecting to my workstation over a ssh connection on the loopback interface and running Evolution there. Evo and the X server are on the SAME HOST, but talking over ssh-forwarded X11. - when Evolution is connected to a Xephyr nested X server running on the same host, connected to the Xephyr X server using a TCP/IP socket over the loopback interface. For example: startx /usr/bin/xterm -- /usr/bin/Xephyr :11 -query localhost \ -screen 1280x1024 .. and in the xterm, running "DISPLAY=127.0.0.1:11 evolution" This issue does not occur: - when Evolution is connected to a native X server running on the same host, connected to the X server using a UNIX domain socket. - when Evolution is connected to a Xephyr nested X server running on the same host, connected to the Xephyr X server using a UNIX domain socket. For example: startx /usr/bin/xterm -- /usr/bin/Xephyr :11 -query localhost \ -screen 1280x1024 .. and in the xterm, running "DISPLAY=:11 evolution"
If you enable your local X server to listen on TCP/IP (on most GNOME desktops, edit /etc/gdm/gdm.conf (may be /etc/X11/gdm/gdm.conf depending on distro/version) and change "DisallowTCP=true" to "DisallowTCP=false" then restart GDM, you can reproduce this running directly on your normal X server. If you run with DISPLAY=:0.0 (assuming you're on DISPLAY 0) the compose window appears in about a second. If you run with DISPLAY=127.0.0.1:0.0 it takes 15 or more seconds to appear. Here's an interesting example. I have two terminals, with prompts "T1$ " and "T2$ ". In T1 I'll launch Evolution, talking on a UNIX domain socket. On T2 I'll then time how long it takes to open a compose window by using the command "time evolution mailto:test@nowhere.org". The remote invocation only terminates when the mail window has displayed, so we can time how long it takes to display quite accurately. Once I've timed that, I'll exit evolution on T1, reopen it with a TCP/IP connection, and repeat the test on T2. Observe the difference: T1$ DISPLAY=:0.0 evolution ** (evolution:26183): DEBUG: EI: SHELL STARTUP ** (evolution:26183): DEBUG: EI: mail_read_notify ** (evolution:26183): DEBUG: MAIL SERVER: Count changed: 0 T2$ time evolution mailto:test@nowhere.org real 0m0.830s user 0m0.160s sys 0m0.030s T1$ DISPLAY=127.0.0.1:0 evolution ** (evolution:26236): DEBUG: EI: SHELL STARTUP ** (evolution:26236): DEBUG: EI: mail_read_notify ** (evolution:26236): DEBUG: MAIL SERVER: Count changed: 0 T2$ time evolution mailto:test@nowhere.org real 0m16.742s user 0m0.180s sys 0m0.030s 0.8 seconds vs 16.7 seconds. The only difference is TCP/IP vs UNIX domain socket comms.
Almost exactly the same time (16.678s) if I use DISPLAY=[::1]:0 to communicate over IPv6. Downloaded and built evolution svn trunk r37529 (Last Changed Date: 2009-04-16 11:34:22 +0800). Tested, same issue. Package versions of interest: ii evolution 2.26.1-0ubuntu2 ii evolution-data-server 2.26.1-0ubuntu1 ii libglib2.0-0 2.20.1-0ubuntu2 ii libgtk2.0-0 2.16.1-0ubuntu2 ii libx11-6 2:1.1.99.2-1ubuntu2 ii xserver-xorg 1:7.4~5ubuntu18 ( evo svn not shown as custom compiled and installed in /opt ) kernel: 2.6.28-11-server $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 9.04 Release: 9.04 Codename: jaunty See the attachments in the Launchpad bug (I won't burden your tracker with them too) for packet traces of the communications between client and server, I/O throughput graphs, etc. When, using Wireshark, I look at what the traffic during the long pause actually is, it's possible to see the same sequence of packets repeated during the long delay: (C: client; S: server) C -> S: Req: TranslateCoordinates S -> C: Rep: TranslateCoordinates C -> S: Req: GrabServer, QueryPointer S -> C: Rep: QueryPointer (* now, repeated seven times *): * C -> S: Req: QueryPointer * S -> C: Rep: QueryPointer (* end repeated segment *) C -> S: Req: UngrabServer The whole segment above repeats hundreds of times during the long delay before the compose window appears.
Tracked down to libgtkhtml . Not an Evolution bug.
Issues in libgtkhtml turned out to be due to gtk/gdk - see bug 585626 for patch and instructions.