Re: With latest snapshot, emacs is very slow to start under X11

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Mar 14 14:45, Ken Brown wrote:
> On 3/14/2014 12:42 PM, Corinna Vinschen wrote:
> > On Mar 14 12:28, Ken Brown wrote:
> >> On 3/14/2014 11:52 AM, Ken Brown wrote:
> >>> With the snapshot of 2014-03-10, start the X server and then run
> >>> "emacs-X11 -Q&" in an xterm window.  On my system, emacs consistently
> >>> takes about 28 seconds to start.  With cygwin-1.7.28, however, it takes
> >>> about 1 second.  This is on Windows 7; so far I've tested 64-bit Cygwin
> >>> only.
> >>>
> >>> I'll try to find the first snapshot that exhibits the problem, and I'll
> >>> also test on 32-bit Cygwin.  But I wanted to make this preliminary
> >>> report quickly, in case the release of 1.7.29 is imminent.
> >>
> >> The problem first occurs with the snapshot of 2014-03-05, and it
> >> occurs only on 64-bit Cygwin.
> > 
> > The only possible explanation is the difference in installing the
> > exception handler, but this is quite puzzeling.  It's the same SEH
> > exception handler installation technique as any mingw64 application
> > uses and mingw64 applications are not known to be excessively slow.
> > 
> > In theory I'm on vacation, though, so I'll look into that next Monday at
> > the earliest.  If you want to test this yourself, try to build a Cygwin
> > DLL with just the patch from 2014-03-04 reverted so that a vectored
> > exception handler is used instead.
> 
> Yes, reverting that patch fixes the problem.

Very, very strange.  This is installing a standard SEH filter function.
I have no idea why this is a problem with Emacs but not with another
application.

> Here are three other data points:
> 
> 1. With a bad DLL, I always see the following warning in the xterm window:
> 
>    WARNING **: Error retrieving accessibility bus address:
>    org.freedesktop.DBus.Error.NoReply: Did not receive a
>    reply. Possible causes include: the remote application did not send
>    a reply, the message bus security policy blocked the reply, the
>    reply timeout expired, or the network connection was broken.
> 
> 2. With both a good DLL and a bad DLL, if I run emacs-X11 under strace [1], I always see one or two exceptions in the strace output.  I assume you'll be able to reproduce the problem and create your own traces, but I've posted mine here, just in case:
> 
>   http://sanibeltranquility.com/cygwin/strace.tar.xz

The problem is this.  The memory addresses given in the straces or in
the below stackdump don't make any sense to me, because I don't have
your DLL.  For clarity it would be helpful to run

  addr2line -e cygwin1.dbg [address...]

so the addresses (the ones starting with 0x0018 at least) can be
conveniently connected to source lines.

> 3. I have a dbus-daemon.exe.stackdump in my home directory, that appeared during my testing.  Unfortunately, I didn't notice it until an hour after it was written, so I have no idea which DLL was in use at the time.  Here are the contents, FWIW:
> 
> Exception: STATUS_ACCESS_VIOLATION at rip=0018016DA05
> rax=000000000000006D rbx=0000000000000000 rcx=00000000FFFFFF95
> rdx=000000000000006D rsi=00000000002290A0 rdi=00000000002290A0
> r8 =0000000000010000 r9 =0000000000000074 r10=000000000000003A
> r11=0000000000228EF0 r12=000000000022A010 r13=0000000600040750
> r14=0000000000000201 r15=00000000002290A0
> rbp=00000000002294D0 rsp=0000000000228F10
> program=C:\cygwin64\bin\dbus-daemon.exe, pid 1904, thread main
> cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
> Stack trace:
> Frame        Function    Args
> 000002294D0  0018016DA05 (00000000000, 00000229038, 7FEFE38E2DF, 00000229E78)
> 000002294D0  00180103D78 (00000229F70, 00000229F70, 00000000000, 000002290A0)
> 000002294D0  00180103F33 (00000340032, 00077C2A3B0, 00000000018, 00000229E78)
> 00000229F70  001800B8080 (00077AFB65E, 00000004000, 00000000044, 000000003E9)
> 0060003C740  001800B8A87 (000000003E9, 0060003C410, 00000000000, 0000022A008)
> 0000022A010  0018011264B (0060003C410, 00000000000, 0000022A008, 00000000000)
> 0000022A010  0000022A130 (00000000000, 0000022A008, 00000000000, 00000000030)
> 0000022A010  000000003E9 (0000022A008, 00000000000, 00000000030, 0000022A010)
> 0000022A010  0060003C410 (0000022A008, 00000000000, 00000000030, 0000022A010)
> End of stack trace
> 
> These three facts suggest that the problem might have something to do with how Cygwin handles an exception that occurs when emacs (or Glib) tries to start a dbus daemon and the latter crashes.  But I'm just guessing.

But why does it crash in the first place?

Using the SEH filter is, strictly speaking, the right thing to do.  The
vectored exception handler is just an ugly workaround in comparison.
Therefore it's quite the bummer that emacs or dbus or whatever, seems
to choke on that.  I'm not familiar enough with exception handling so
I can't guarantee that I find a solution which is working in all cases.
I was glad enough when Kai Tietz (our Mingw64 maintainer) pointed out
the SEH filter solution used Mingw64.  I'm using it in exactly the
same way as Mingw64 is using it :(

Why is it always emacs?  Vim works fine...


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgpezFo8YY_1W.pgp
Description: PGP signature