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

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.


[1] Using a good DLL, there are two exceptions, one of which occurs very early.  Using a bad DLL, I can't actually run emacs-X11 under strace for very long, because emacs (or strace?) terminates when the first exception occurs.  Instead, I have to start emacs and then attach strace.

Problem reports:
Unsubscribe info:

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