Mail Archives: cygwin/2014/03/15/12:35:48
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
- Raw text -