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=n4DfaM99i/emBjGwNrbmEvtpo7NdVFp/V0F9wqlKY7t KLFiEqD3uW5EnmH0wKabXw8srmj7Vol26cD6zR8SSKOhdl41ZSmsku46Um3w8X5B i0FE8gHA2k8ZT7LIQ/7Hb8H7gpJt7/pqWv8OQF17BYxklvImiZgUnTK0gOEBl6JE = 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=9T/bNm9BoJl78fJ0oPq4tRyTU1A=; b=SaiQ9gYrL8RHiWKT+ zAU/cvxSI9b3Denxkna5rMtlFqUk0AVqrK4snLjVcERF+Fy8zqqDZwG90JglRR6u gN2Zp71eOkiobCrQ2a+qFtLObWyI0JT6EzM3DsUVij32tDMstLsMhs6p69K3jaQp OWEadieE0/ihQogdOqFIt5h7+w= 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.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_JMF_BR,SPF_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: limerock03.mail.cornell.edu X-CornellRouted: This message has been Routed already. Message-ID: <5327203A.9050704@cornell.edu> Date: Mon, 17 Mar 2014 12:18:02 -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> <53248149 DOT 2000007 AT cornell DOT edu> <20140316115307 DOT GC400 AT calimero DOT vinschen DOT de> <532666CE DOT 8 AT cornell DOT edu> In-Reply-To: <532666CE.8@cornell.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes On 3/16/2014 11:06 PM, Ken Brown wrote: > On 3/16/2014 7:53 AM, Corinna Vinschen wrote: >> On Mar 15 12:35, Ken Brown wrote: >>> On 3/14/2014 4:19 PM, Corinna Vinschen wrote: >>>> 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. >> >> Thanks. What makes me wonder is the long time emacs is waiting >> for dbus. This doesn't make sense in terms of exception handling. >> It sounds a bit as if it's *really* waiting for some reason and >> the question is, what exactly is it waiting for (socket timeout?) >> and why didn't it wait before? > > It turns out that it's various glib functions that are waiting (see > below). I don't know why they didn't wait before. >> >>>>> 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. >> >> That would be incredibly helpful. There is a chance that the old >> exception handling didn't work as expected and therefore covered >> something under the hood. > > That seems likely. See below. > >>>> 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. >> >> Nah, never mind. I'm just frustrated, is all. > > It turns out that this has nothing to do with emacs after all, but it's > a problem with glib and/or dbus. I get the exact same behavior with the > following program, copied from > https://developer.gnome.org/gtk3/3.0/gtk-getting-started.html, which > simply pops up a small empty window: > > $ cat window-default.c > #include > int > main (int argc, char *argv[]) > { > GtkWidget *window; > gtk_init (&argc, &argv); > window = gtk_window_new (GTK_WINDOW_TOPLEVEL); > g_signal_connect (window, "destroy", G_CALLBACK (gtk_main_quit), NULL); > gtk_widget_show (window); > gtk_main (); > return 0; > } > > $ gcc $(pkg-config --cflags gtk+-3.0) -o window-default > window-default.c $(pkg-config --libs gtk+-3.0) > > Now start the X server and give the following commands in an xterm > window running a bash shell: > > $ eval $(dbus-launch --sh-syntax) # this starts a dbus daemon > > $ ./window-default.exe & > > Under cygwin-1.7.28, the empty window pops up immediately. Under the > latest snapshot, there's a long delay, after which the following message > appears in the xterm window: > > ** (window-default:10812): 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. > > After another delay, the following additional messages appear, and the > empty window pops up: > > Error creating proxy: Error calling StartServiceByName for > org.gtk.vfs.Daemon: Timeout was reached (g-io-error-quark, 24) > > (window-default:1556): GVFS-CRITICAL **: fill_mountable_info: assertion > `proxy != NULL' failed > > I did a little debugging in gdb and found that the first delay is caused > by a timeout in a call to "dbus_connection_send_with_reply_and_block" > (defined in dbus-connection.c in the dbus sources). This in turn is > called by "get_accessibility_bus_address_dbus" in atspi-misc.c in the > at-spi2-core sources. I think the second delay is also caused by a > timeout in a call to the same function, this time coming from gvfs, but > I don't remember for sure any more. > > I hope someone who knows about glib and dbus (Yaakov?) can help at this > point. One further detail: An strace of window-default shows the same two exceptions that I saw in the emacs straces. These presumably correspond to the two delays mentioned above. I tried stepping through dbus_connection_send_with_reply_and_block to see if I could see where the exceptions were coming from, but I couldn't. 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