This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 3/14/2014 4:19 PM, Corinna Vinschen wrote:
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.

Sorry, I meant to say that the straces were made from cygwin-1.7.28-2 ("good DLL") and the 2014-03-10 snapshot ("bad DLL"). The addresses of the exceptions in the straces all point to thread.cc:144. I can't do anything with the stackdump below because, as I said, I don't know which DLL I was using when the crash occurred. All I know is that it was from one of the snapshots, because it happened while I was bisecting.

I'll keep testing and see if I can get another stackdump.

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?

I have no idea.  I'll see if I can figure anything out.

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...

Sorry.

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]