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

[Ken Brown]

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