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: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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 <kbrown AT cornell DOT edu>
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 <gtk/gtk.h>
> 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