Re: Killing a frame sometimes kills emacs

[Tassilo Horn]

James Cloos <address@hidden> writes:

> TH> So as soon as I mix these two invocation styles, (x-display-list)
> TH> returns (":0" ":0.0").  Those displays are different, and when I
> TH> delete the last frame on one of the (equivalent) displays, emacs
> TH> (including the original frames on the other displays) are killed.
>
> It seems, then, that emacs needs to canonicalize the DISPLAY strings
> before comparing them.

It's not that emacs kills itself.  It segfaults probably because gtk
deletes/frees the display while emacs is still using it.  (Well, or
something like that...)

Oh, checking the backtrace I've posted at the beginning of this thread,
I've found this code in gtkutil.c:

--8<---------------cut here---------------start------------->8---
#if GTK_MAJOR_VERSION == 2 && GTK_MINOR_VERSION < 10
  /* GTK 2.2-2.8 has a bug that makes gdk_display_close crash (bug
     http://bugzilla.gnome.org/show_bug.cgi?id=85715).  This way we
     can continue running, but there will be memory leaks.  */
  g_object_run_dispose (G_OBJECT (gdpy));
#else
  /* This seems to be fixed in GTK 2.10. */
  gdk_display_close (gdpy);
#endif
}
--8<---------------cut here---------------end--------------->8---

That's already the right workaround, isn't it?  The only thing is that
this bug is *not* fixed in GTK 2.10 but instead still exists (or exists
again) in GTK 3.2.0.

Bye,
Tassilo