With latest snapshot, emacs is very slow to start under X11

[Ken Brown]

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