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=t1OEFHfuaGWgs/D/fc/TRUp6w4kw0Egny40OxFKBA3a
	dX8oFfRcWQhJU6G9o1WIps+34w/f4A74Xx+wggESzzZjSnThIrAS8y9Ro9BeySLa
	U4LryxggXrPJGFqGm2OKawaj+lAt3ZG4xDKayLYdWsq8RX7gDGrMPel8/iOHRE/I
	=
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=OzxKfpWCqGa6rH2PmaBJQin9EYw=; b=tmRoG4LN9/x/lmoeV
	ay8nhmU0Rrvnci/cPz4yGssH8PWqrWzPX7xNmTsazn/JyGzFiYVsmj3NQlKX5SQ5
	9okzyZ2PCg/LxIzTFa4s3qlLzg1qzD2AB2J7eH/iymTtkAfwHd2TBqN5PJtKi3N5
	KV8HOiKeY/aBpsV0lF8FhcAgqI=
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.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO:	limerock01.mail.cornell.edu
X-CornellRouted:	This message has been Routed already.
Message-ID:	<532666CE.8@cornell.edu>
Date:	Sun, 16 Mar 2014 23:06:54 -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>
In-Reply-To:	<20140316115307.GC400@calimero.vinschen.de>
X-IsSubscribed:	yes

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.

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 -