X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; q=dns; s=default; b=t8dB8LpUaL6bbwFA72DSgjPmZERpqDZ/PAenQCn8Itp EKaJokBwTtk6CqlPNnerc64WTMddXaD3prGLIKLtgCgCgz2MB2tCcgvMjJxMnjxG RG6HPvcj43wyxbBfaBmjpekzo134IOcw4qKbHS0hXNMqiVhmJsFCu24o6FKHqJn0 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; s=default; bh=ft/J9FGShfLOH5il+mF8bIavrzs=; b=cf+wwtuizSWiRkpmR bgo8wCfSCoNoLfu/ZzKP7gFU/oGvgKsA0Tf8hpKS3H0cxFm6RIIEUbPVIydTaqgY pcXIppSZVuT3O+Mdq154dsW5Wl81YN0nXidjoj0NlXjy2GZ8I3qqpZQYiPdYZePM ghHNIEec81VWcZeCQlNx43ozfw= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: limerock04.mail.cornell.edu X-CornellRouted: This message has been Routed already. Message-ID: <53248149.2000007@cornell.edu> Date: Sat, 15 Mar 2014 12:35:21 -0400 From: Ken Brown User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: With latest snapshot, emacs is very slow to start under X11 References: <532325A5 DOT 5020103 AT cornell DOT edu> <53232E30 DOT 3080801 AT cornell DOT edu> <20140314164243 DOT GD2355 AT calimero DOT vinschen DOT de> <53234E31 DOT 8030805 AT cornell DOT edu> <20140314201916 DOT GG2355 AT calimero DOT vinschen DOT de> In-Reply-To: <20140314201916.GG2355@calimero.vinschen.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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