Re: Killing a frame sometimes kills emacs

[Tassilo Horn <tassilo@member.fsf.org>]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Oh, checking the backtrace I've posted at the beginning of this thread,
> I've found this code in gtkutil.c:
>
> #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
> }
>
> 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.

I've just commented the line in the #else and recompiled emacs and
reproduced the issue, i.e., started emacs using the application menu
(resulting in a frame on display :0) and then opened another frame using
emacsclient -c in a gnome terminal, so that in the end (x-display-list)
returned (":0" ":0.0").

Then I deleted the frame created by emacsclient -c using C-x 5 0.  The
result is that the frame is still there but not functional.  I can't
even see the mouse pointer when hovering over it.  From my perspective,
that's an improvement. :-)

(x-display-list) returns (":0") again.

Bye,
Tassilo