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.