This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Mar 17 12:18, Ken Brown wrote:
> On 3/16/2014 11:06 PM, Ken Brown wrote:
> >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.

This exception is expected, if some pthread function uses an
uninitialized object and usually non-critical.

I'm looking into this myself and I really don't grok this.  I'm
inclined to revert to VEH and be done with it.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgps_dlMGBc8f.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]