[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Killing a frame sometimes kills emacs
From: |
Tassilo Horn |
Subject: |
Re: Killing a frame sometimes kills emacs |
Date: |
Tue, 11 Oct 2011 21:49:30 +0200 |
User-agent: |
Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux) |
Tassilo Horn <address@hidden> 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
Re: Killing a frame sometimes kills emacs, Jan Djärv, 2011/10/11