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
pgpUlsaTbRGDL.pgp
Description: PGP signature
