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

[Ken Brown]

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