Mail Archives: cygwin/2014/03/14/16:19:38
--QXO0/MSS4VvK6f+D
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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 tak=
es
> >>> about 1 second. This is on Windows 7; so far I've tested 64-bit Cygw=
in
> >>> 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.
> >=20
> > 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.
> >=20
> > 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.
>=20
> 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:
>=20
> 1. With a bad DLL, I always see the following warning in the xterm window:
>=20
> 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.
>=20
> 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'l=
l be able to reproduce the problem and create your own traces, but I've pos=
ted mine here, just in case:
>=20
> 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.
> 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 a=
re the contents, FWIW:
>=20
> Exception: STATUS_ACCESS_VIOLATION at rip=3D0018016DA05
> rax=3D000000000000006D rbx=3D0000000000000000 rcx=3D00000000FFFFFF95
> rdx=3D000000000000006D rsi=3D00000000002290A0 rdi=3D00000000002290A0
> r8 =3D0000000000010000 r9 =3D0000000000000074 r10=3D000000000000003A
> r11=3D0000000000228EF0 r12=3D000000000022A010 r13=3D0000000600040750
> r14=3D0000000000000201 r15=3D00000000002290A0
> rbp=3D00000000002294D0 rsp=3D0000000000228F10
> program=3DC:\cygwin64\bin\dbus-daemon.exe, pid 1904, thread main
> cs=3D0033 ds=3D002B es=3D002B fs=3D0053 gs=3D002B ss=3D002B
> Stack trace:
> Frame Function Args
> 000002294D0 0018016DA05 (00000000000, 00000229038, 7FEFE38E2DF, 00000229=
E78)
> 000002294D0 00180103D78 (00000229F70, 00000229F70, 00000000000, 00000229=
0A0)
> 000002294D0 00180103F33 (00000340032, 00077C2A3B0, 00000000018, 00000229=
E78)
> 00000229F70 001800B8080 (00077AFB65E, 00000004000, 00000000044, 00000000=
3E9)
> 0060003C740 001800B8A87 (000000003E9, 0060003C410, 00000000000, 0000022A=
008)
> 0000022A010 0018011264B (0060003C410, 00000000000, 0000022A008, 00000000=
000)
> 0000022A010 0000022A130 (00000000000, 0000022A008, 00000000000, 00000000=
030)
> 0000022A010 000000003E9 (0000022A008, 00000000000, 00000000030, 0000022A=
010)
> 0000022A010 0060003C410 (0000022A008, 00000000000, 00000000030, 0000022A=
010)
> End of stack trace
>=20
> These three facts suggest that the problem might have something to do wit=
h 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?
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...
Corinna
--=20
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--QXO0/MSS4VvK6f+D
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJTI2REAAoJEPU2Bp2uRE+gcu8P/R7rYB+/3tUdiCzFZODngRTq
FGL9BHZ5rcNBRpdhQkNPAAblVEbuWYpF+88dHcFI1PtGszBuJrZGe2AZ3O0KEQbE
/c/TpwXJXYIV+rCNBhJlL3JUts7sW4AHb7q7KZIIR4IoMdXZFlppG5A3YQ1/SLam
pA5oSdDtepKKiwtid5XV6OhINVgJwk2oREiqMT9rPgAx9b+lf8CKt8r5tVfJe65S
oaMuBUG/7VAv7HI8nzWoBSi0CI9+23KmuBMp22ZeR4HlQHzORcnrLK0auU6SuQ1B
c9dWfnSC2wbxR2M0jpkN/KJ6qstRDMmmMswlzz437cQMd9cU7Zr3fWaEA7UPjeAG
xpTkQHnAnENDb1jCufXh7ZGulEfoeF/hDjQ7l5bndUlP1GzdIBVKq56JQboQz3qE
5YOa4DwSaUrBnCRJM5wRenkYA1At3J9/6GYUnIvrjxQf8q+Brbz7Zc9d4tOmcZTh
vMpa4IrzGjnqMzHe+VoFDlfjaPi9ZCfd5BY49F67DBDOiznJCr827BSL4LxrcSeG
JWDAgXn9kCGd1gSL6dPLq9DIba+zRhSm0VfCjygokkRHTmC/AiaSiBshgM2e9uHQ
EnAKiBADLocxY5A3cDmZEDNGs2wvG67XEtbF/Qaaxabbo13mfE++AMNhl6NuHh1R
b/uXi3NYFQWKHXgsQ/8n
=XpHe
-----END PGP SIGNATURE-----
--QXO0/MSS4VvK6f+D--
- Raw text -