GNOME Bugzilla – Bug 85715
Closing displays
Last modified: 2019-06-18 12:13:43 UTC
http://mail.gnome.org/archives/gtk-devel-list/2002-June/msg00129.html Describes a plan for adding the ability to close displays to GTK+-2.2. Some additional particular items that need fixing: - gdk_x11_display_finalize() needs some careful going over; there is a lot of stuff it leaves un-freed. For instance the ClientFilter objects in the client_filters list. - gdk_x11_screen_finalize() also needs a lot of attention. - gdk_display_close() just unrefs currently; it *should* unref (if the display hasn't already been closed) but has to do a lot more as well. - A lot of caches need to be freed when the display is dispposed; along with ones mentioned in the mail message, a few others are the scratch_image information in gdkimage.c and the pixmap catch in gtktree.c. (Although gtktree.c could just be left, since it's a GTK_ENABLE_BROKEN widget.)
The API stuff should be done now, though there still is a lot of work in the implementation details.
Rest of the details will have to wait for 2.4.
*** Bug 107217 has been marked as a duplicate of this bug. ***
A quick patch that documents this: http://web.ics.purdue.edu/~eblanton/gtk/gtk+-2.2.1-gdk_display_close-doc.diff
*** Bug 113542 has been marked as a duplicate of this bug. ***
*** Bug 126579 has been marked as a duplicate of this bug. ***
bug 126579 tracks down one particular crash when closing displays.
Created attachment 22483 [details] [review] fix a number of close issues / crashers.
Don't think there is a huge value in fixing a few things piecemeal, so I'd rather apply this patch only on the 2.6 devel branch when that opens.
So this can go in HEAD now, I guess.
*** Bug 148812 has been marked as a duplicate of this bug. ***
*** Bug 161558 has been marked as a duplicate of this bug. ***
Created attachment 45825 [details] [review] Patch that fixes crashes and cleans up some more stuff Attached patch does everything the patch in comment #8 does. Additionally it frees more stuff that was previously leaked. And it needs review, esp. the part where I hack badly to be able to destroy the root window.
Created attachment 45943 [details] [review] Updated patch Updated patch adds finalization of the closed screen's GdkVisuals.
Created attachment 45948 [details] [review] Next update Adds finalization of GdkKeymapX11
Here is my own patch from last December. I haven't done any comparison to your patch yet. From what I remember, my patch was incomplete wrt to actual closing of displays, but it had the necessary pieces for a protocol to let e.g. the wm initiate migration of windows. This, together with a cmdline utility for starting a migration, can be found at http://people.redhat.com/mclasen/migration
Created attachment 46014 [details] [review] Merged patch Attached patch merges in some changes from Matthias' patch, namely proper root window destruction and some parts that i considered nicer in Matthias' patch than in my own. Didn't merge any of the display migration changes. Merged patch should be free from any hacks now that root window destruction is de-uglyfied.
Hmm, the gtk-demo change display example seems to still crash for me, with the patch. I haven't looked in detail yet.
Created attachment 46108 [details] [review] Next update on_renderer_display_closed() in gdkpango.c had the wrong signature. gtk-demo crashes on XFreeGC() in gdk_gc_x11_finalize() now. I tried to debug that with some simple g_print(), but I don't have the setup to debug inside xlib right now.
Created attachment 46110 [details] [review] Nect one Unsets xdisplay, screen etc members *after* chaining up in gdk_screen_x11_dispose(), so x11 implementations of members destroyed by the parent class (namely GdkGCs) have a chance to call xlib functions. The update also adds some "member = NULL" lines in gdk_screen_dispose(), they would probably have crashed next :) In gtk-demo, I can close a display now after moving a window there and back.
*** Bug 304608 has been marked as a duplicate of this bug. ***
As per root problem which caused me to debug and submit bug 304608: gtk_init seems to be a preferred way to initialize gtk, but it was not clear to me how to shut gtk down so that all (modulo bugs) resources are freed prior to exit? I needed that for Mozilla. I ended up with a hack. See https://bugzilla.mozilla.org/show_bug.cgi?id=293007: // gtk_init() -> gtk_init_check(): // return gdk_display_open_default_libgtk_only () != NULL; // thus we lost GdkDisplay* inside gtk_init! Due to Xft font caching more than megabyte was not freed because of this. Neither app examples nor source around gtk_init() implementation have any hints.
Summary of problems with 2.6.7 when I try to close last GdkDisplay (see Mozilla's bugzilla for details): gdkdisplay-x11.c: gdk_display_x11_dispose(): crash if display_x11->xdisplay==NULL gdk_display_x11_finalize(): same _gdk_windowing_set_default_display(display): does not handle NULL parameter (this happens on 'close last GdkDisplay' codepath) gdkgc-x11.c: gdk_gc_x11_finalize(): if user has closed all GdkDisplays, it calls XFreeGC(NULL,...) - which crashes
All these issues and more are addressed in the attached patch #46110.
I am trying to close default GdkDisplay on exit from Mozilla by adding gdk_display_close(gdk_display_get_default()); just before end of main() (see https://bugzilla.mozilla.org/show_bug.cgi?id=293007) Stock gtk 2.6.7 segfaults. gtk 2.6.7 patched with patch #4611 segfaults. Looks like use-after-free. Valgrind trace (abridged): Addrcheck, a fine-grained address checker for x86-linux. Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. Using valgrind-2.4.0, a program supervision framework for x86-linux. Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. My PID = 26929, parent PID = 26927. Prog and args are: /usr/app/mozilla-2005-05-08/mozilla-bin For more details, rerun with: -v Invalid read of size 4 at 0x34824CB5: g_hash_table_lookup_node (in libglib-2.0.so.0.600.4) by 0x34825030: g_hash_table_remove (in libglib-2.0.so.0.600.4) by 0x346FA079: _gdk_xid_table_remove (in libgdk-x11-2.0.so.0.600.7) by 0x346EB158: gdk_pixmap_impl_x11_finalize (in libgdk-x11-2.0.so.0.600.7) by 0x347C822B: g_object_last_unref (in libgobject-2.0.so.0.600.4) by 0x347CB42C: g_object_unref (in libgobject-2.0.so.0.600.4) by 0x346BC839: gdk_pixmap_finalize (in libgdk-x11-2.0.so.0.600.7) by 0x347C822B: g_object_last_unref (in libgobject-2.0.so.0.600.4) by 0x347CB42C: g_object_unref (in libgobject-2.0.so.0.600.4) by 0x344838CC: free_gc_drawable (in libgtk-x11-2.0.so.0.600.7) by 0x348257DB: g_hash_nodes_destroy (in libglib-2.0.so.0.600.4) by 0x34824C0B: g_hash_table_destroy (in libglib-2.0.so.0.600.4) by 0x3481E50D: g_datalist_clear_i (in libglib-2.0.so.0.600.4) by 0x3481E3FA: g_datalist_clear (in libglib-2.0.so.0.600.4) by 0x347C8189: g_object_finalize (in libgobject-2.0.so.0.600.4) by 0x346ED2DD: gdk_screen_x11_finalize (in libgdk-x11-2.0.so.0.600.7) by 0x347C822B: g_object_last_unref (in libgobject-2.0.so.0.600.4) by 0x347CB42C: g_object_unref (in libgobject-2.0.so.0.600.4) by 0x346D1A4B: gdk_display_x11_finalize (in libgdk-x11-2.0.so.0.600.7) by 0x347C822B: g_object_last_unref (in libgobject-2.0.so.0.600.4) by 0x347CB42C: g_object_unref (in libgobject-2.0.so.0.600.4) by 0x346AFDE1: gdk_display_close (in libgdk-x11-2.0.so.0.600.7) by 0x804E0D6: main (in mozilla-bin) Address 0x34CA06A8 is 8 bytes inside a block of size 28 free'd at 0x341467B9: free (vg_replace_malloc.c:152) by 0x3483908B: g_free (in libglib-2.0.so.0.600.4) by 0x34824C3A: g_hash_table_destroy (in libglib-2.0.so.0.600.4) by 0x346D19A8: gdk_display_x11_finalize (in libgdk-x11-2.0.so.0.600.7) by 0x347C822B: g_object_last_unref (in libgobject-2.0.so.0.600.4) by 0x347CB42C: g_object_unref (in libgobject-2.0.so.0.600.4) by 0x346AFDE1: gdk_display_close (in libgdk-x11-2.0.so.0.600.7) by 0x804E0D6: main (in mozilla-bin) Invalid read of size 4 at 0x34824CBB: g_hash_table_lookup_node (in libglib-2.0.so.0.600.4) by 0x34825030: g_hash_table_remove (in libglib-2.0.so.0.600.4) by 0x346FA079: _gdk_xid_table_remove (in libgdk-x11-2.0.so.0.600.7) by 0x346EB158: gdk_pixmap_impl_x11_finalize (in libgdk-x11-2.0.so.0.600.7) by 0x347C822B: g_object_last_unref (in libgobject-2.0.so.0.600.4) by 0x347CB42C: g_object_unref (in libgobject-2.0.so.0.600.4) by 0x346BC839: gdk_pixmap_finalize (in libgdk-x11-2.0.so.0.600.7) by 0x347C822B: g_object_last_unref (in libgobject-2.0.so.0.600.4) by 0x347CB42C: g_object_unref (in libgobject-2.0.so.0.600.4) by 0x344838CC: free_gc_drawable (in libgtk-x11-2.0.so.0.600.7) by 0x348257DB: g_hash_nodes_destroy (in libglib-2.0.so.0.600.4) by 0x34824C0B: g_hash_table_destroy (in libglib-2.0.so.0.600.4) by 0x3481E50D: g_datalist_clear_i (in libglib-2.0.so.0.600.4) by 0x3481E3FA: g_datalist_clear (in libglib-2.0.so.0.600.4) by 0x347C8189: g_object_finalize (in libgobject-2.0.so.0.600.4) by 0x346ED2DD: gdk_screen_x11_finalize (in libgdk-x11-2.0.so.0.600.7) by 0x347C822B: g_object_last_unref (in libgobject-2.0.so.0.600.4) by 0x347CB42C: g_object_unref (in libgobject-2.0.so.0.600.4) by 0x346D1A4B: gdk_display_x11_finalize (in libgdk-x11-2.0.so.0.600.7) by 0x347C822B: g_object_last_unref (in libgobject-2.0.so.0.600.4) by 0x347CB42C: g_object_unref (in libgobject-2.0.so.0.600.4) by 0x346AFDE1: gdk_display_close (in libgdk-x11-2.0.so.0.600.7) by 0x804E0D6: main (in mozilla-bin) Address 0x34CA06AC is 12 bytes inside a block of size 28 free'd at 0x341467B9: free (vg_replace_malloc.c:152) by 0x3483908B: g_free (in libglib-2.0.so.0.600.4) by 0x34824C3A: g_hash_table_destroy (in libglib-2.0.so.0.600.4) by 0x346D19A8: gdk_display_x11_finalize (in libgdk-x11-2.0.so.0.600.7) by 0x347C822B: g_object_last_unref (in libgobject-2.0.so.0.600.4) by 0x347CB42C: g_object_unref (in libgobject-2.0.so.0.600.4) by 0x346AFDE1: gdk_display_close (in libgdk-x11-2.0.so.0.600.7) by 0x804E0D6: main (in mozilla-bin) ...
Created attachment 47018 [details] [review] Minimal patch against gtk 2.6.7 with which Mozilla doesnt segfault
Created attachment 54135 [details] [review] patch ported to HEAD Here's an updates patch that could go into HEAD. Changes from previous version are: - gdk_display_dispose() sets the most recently opened display as the new default one, instead of always setting the default to NULL - fixed display closing crashs/warnings in gtkclipboard.c and gtktextdisplay.c With the patch applied, the following works fine in gtk-demo: - open :2.0 - move gtk-demo window there - close :0.0 - re-open :0.0 - move gtk-demo window back - close :2.0 - quit normally
Thanks Michael! gtkdemo works here also. I get a segfault migrating Ethereal to another display. It segfaults only if the original display is closed. Ethereal 0.10.12 (plus a few lines to migrate with gtk_window_set_screen), with GTK+ 2.8.6 + patch from Attachment #54135 [details]. Backtrace is below. Let me know if I can provide any more information.
+ Trace 63956
Yea, I bet there are still several ways to crash it by changing/closing the old display. See the stack trace in comment #25. It definitely also leaks some stuff. However I'd prefer to fix this stuff on top of the patch that works for gtk-demo, it has grown quite large already and doesn't become easier to read when adding more fixes :)
please commit the patch mitch, it fixes a load of issues and looks very good to me. you're completely right, we can work out other segfaults/issues on top of the set of fixes you already.
Agreed, looks like a step in the right direction. Lets commit it and work from there on the remaining issues.
Ok, comitted: 2005-11-10 Michael Natterer <mitch@imendio.com> Applied patch from maemo-gtk that addresses many issues wrt display migration and display closing (bug #85715). * gdk/gdkdisplay.c (gdk_display_dispose): don't just set the default display to NULL when it's closed. Instead set the most recently opened display as new default (if one exists). * gdk/gdkpango.c (on_renderer_display_closed): fixed signature of this callback. * gdk/gdkscreen.c (gdk_screen_dispose): check if the GCs still exist before unrefing them. * gdk/gdkwindow.c (_gdk_window_destroy_hierarchy): if the screen is closed, allow destruction of the root window. * gdk/x11/gdkdisplay-x11.c: moved some stuff from finalize() to dispose(), free stuff that was leaked before. * gdk/x11/gdkevents-x11.c (_gdk_x11_events_uninit_screen): check if the xsettings_client still exists before destroying it. * gdk/x11/gdkkeys-x11.c: added finalization and free the allocated X resources. * gdk/x11/gdkpixmap-x11.c: moved stuff from finalize() to new dispose() implementation. * gdk/x11/gdkscreen-x11.c: moved stuff from finalize() to dispose() and check if it still exists before unrefing it. Set their pointers to NULL/None *after* upchaining in dispose(), because X11 implementations of members of the parent class still need them for their own destruction. * gdk/x11/gdkvisual-x11.c: removed finalize() implementation which was g_error()ing when finalizing a visual. * gtk/gtkclipboard.c (gtk_clipboard_finalize): don't use get_clipboard_widget() because it would create the widget if it doesn't exist. Use g_object_get_data() directly instead. * gtk/gtktextdisplay.c (on_renderer_display_closed): fixed signature of this callback.
Argl, accidentially set to NEEDINFO, reopening.
Ethereal still fails with a BadPixmap error from X, even without closing the display. Next test was gedit. It works fine if the display is not closed. If it is however, I get the crash in the attached file.
Created attachment 54727 [details] Errors and backtrace from migrating gedit to a new display
Looks the program is screwed long before the crash happens. Would be interesting to see a stack trace of the first critical warning.
This commit should fix the crashers from comment #25 and comment #28: 2005-11-15 Michael Natterer <mitch@imendio.com> * gdk/x11/gdkdisplay-x11.c (gdk_display_x11_finalize): destroy display->xid_ht as late as possible (right before XCloseDisplay) because it still needs to be around when the display's screens are finalized. (#85715)
Created attachment 54782 [details] backtrace from the first assertion in moving gedit Triggered a SIGSTOP on the assertion in g_log and this is the backtrace. The pango errors from the previous log appear if text is typed in gedit before closing the screen.
More stuff cleaned up correctly on display close: 2005-11-16 Michael Natterer <mitch@imendio.com> * gdk/x11/gdkevents-x11.c (_gdk_events_uninit): new internal function which destroys the display's event source. Also removes the source from the global display_sources list and unrefs it. * gdk/x11/gdkprivate-x11.h: declare the function. * gdk/x11/gdkdisplay-x11.c (gdk_display_x11_dispose): call it instead of half-destroying the source here.
Created attachment 56758 [details] [review] Fix display migration of GtkMenuToolButton GtkMenuToolButton was not using gtk_menu_attach_to_widget() and gtk_menu_detach(), resulting in broken behavior upon screen/display change. Attached patch fixes this.
thanks mitch, the GtkMenuToolButton changes look good to me, please apply.
Applied to HEAD: 2006-01-04 Michael Natterer <mitch@imendio.com> * gtk/gtkmenutoolbutton.c (gtk_menu_tool_button_set_menu) (gtk_menu_tool_button_destroy): use gtk_menu_attach_to_widget() and gtk_menu_detach() instead of reffing/unreffing the menu manually. Also fixes brokenness on screen change (bug #85715).
One more small fix: 2006-01-10 Michael Natterer <mitch@imendio.com> * gdk/gdkpango.c (on_renderer_display_closed): disconnect from the right object ("closed" is emitted by the display, not the screen). (bug #85715)
Get rid of scratch GdkImages when the display closes: 2006-01-12 Michael Natterer <mitch@imendio.com> * gdk/gdkimage.c (scratch_image_info_for_depth): connect to the display's "closed" signal and free the cached scratch images upon display closing (bug #85715).
Another one: 2006-01-23 Michael Natterer <mitch@imendio.com> * gtk/gtkcolorbutton.c: move destruction of the private GdkGC from finalize() to unrealize(). Fixes BadMatch on display change (bug #85715).
Mitch, what is the status of this ? Any work left ?
*** Bug 335083 has been marked as a duplicate of this bug. ***
I'm not aware of anything that's still broken (even tho there probably is), but I left the bug open because new issues were appearing regularly. However, properly closing the display needs heavy support from the app. It must move away or close all its windows and other display related resources, then it must call gdk_display_close(). Only then it's safe to actually close the display. That's not exactly "toolkit support" for display closing, it's rather the tookit supporting the app to do it. It's also still the app that needs explicit support for moving windows between screens/displays. Do we want support for randomly closing the display, without the app crashing? That would require implementing some if the stuff from Owen's initial proposal, like marking all its resources "dead" and silently doing nothing with them until the app came around destroying them or moving them to another display. What we probably want is toolkit support for moving any window to other screens without extensive app support. Adding an API like the proposed gtk_widget_set_can_change_screen() sounds like a reasonable way. Do we want to collect all these issues in the same bug report? This one has grown rather large in the meantime :)
Moving off 2.10 Freeze; but as you say, it may be better to close this one and open new ones as required.
I've a patch [overstatement... a mass of changes admist many others] which handles the miscellany by making any object that uses a screen take a ref (such as toplevels, styles, gcs, drawables, etc) and the screen take a ref on the display. The screen/display dispose/finalize are rebalanced to keep the connection (and associated bookkeeping) usuable until finalize. The display->screen->display ref cycle is broken by the explicit run_dispose from gdk_display_close and then natural attrition causes the display to shutdown with its last user. This appears to handle the random closure case, although I've not checked how honoured display->closed truely is.
I think I just ran into this (or the issue it has become in #48 and #50). My initial telemetry is that nothing took a ref on the GdkScreen (or GdkDisplay, it's all a bit circular) in the first place, and so when I go and do something innocent like get a GdkScreen with gtk_window_get_screen(), ref it, use it, and then unref it when I'm done, it appears to drop ref count to zero, and, gaboom. Gdk-ERROR **: attempted to destroy root window aborting... I'll open a new bug if I can confirm any of this with an isolated test case. AfC
Years later re comment #51: Andrew, can you attach some small test code that crashes in that case?
(In reply to comment #52) > Years later re comment #51: > > Andrew, can you attach some small test code that crashes in that case? > Here's a different test case, using the recently released emacs-23.1 (older versions don't support the necessary features): $ emacs -Q -nw -f server-start from a different xterm: $ emacsclient -c -n this will create a Gtk+ emacs window use xkill to kill that window now do again: $ emacsclient -c -n this should create a new emacs window, but it does not and a lot of assertions are printed in the original xterm. This only happens when emacs is configured to use Gtk+ (the default). If emacs is configured with: ./configure --with-x-toolkit=lucid this problem does not happen. This is on an up to date Fedora 11 system, Gtk+ 2.16.1
For more test cases and backtraces, see https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/543611
The bug still exists with GTK+ 3.0.11. Tested with Emacs from BZR (revision 104859 of trunk).
FWIW, I still see the problem with Emacs (using Debian testing's 3.4.2).
Any chance to see this bug fixed?
*** Bug 645176 has been marked as a duplicate of this bug. ***
*** Bug 683815 has been marked as a duplicate of this bug. ***
SIGABRT launching emacs (without any arg) emacs 24.3 gtk 3.11.5 fedora rawhide (gdb) bt
+ Trace 233141
Created attachment 269195 [details] Backtrace (too long to fit in comment) emacs 23.3.1, gtk 3.11.5 with or without any args on start. Output on stderr refers to this bug.
I also can reproduce it w/ emacs and gtk 3.11.5
(In reply to comment #61) (In reply to comment #62)
(In reply to comment #61) (In reply to comment #62) Please keep in mind that recent Emacs versions shut down before this bug can actually occur. In xterm.c of Emacs 24.3, function x_connection_closed: #ifdef USE_GTK /* A long-standing GTK bug prevents proper disconnect handling (https://bugzilla.gnome.org/show_bug.cgi?id=85715). Once, the resulting Glib error message loop filled a user's disk. To avoid this, kill Emacs unconditionally on disconnect. */ shut_down_emacs (0, Qnil); fprintf (stderr, "%s\n\ When compiled with GTK, Emacs cannot recover from X disconnects.\n\ This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715\n\ For details, see etc/PROBLEMS.\n", error_msg); emacs_abort (); #endif /* USE_GTK */ So make sure that you have disabled this code block before testing, otherwise your confirmation reports will be worthless.
(In reply to comment #64) > > Please keep in mind that recent Emacs versions shut down before this bug can > actually occur. In xterm.c of Emacs 24.3 (...) yes even removing this, emacs_abort() happens somewhere else, but I'm not sure anymore this bugzilla is the right one? (gdb) bt
+ Trace 233200
I am seeing the same problem; setting XLIB_SKIP_ARGB_VISUALS=1 seems to mitigate the problem on startup. However, starting emacs like this, in many situations I get additional SEGFAULTS: gdk_x11_window_foreign_new_for_display on gdkwindow-x11.c:1238 calls XVisualIDFromVisual with visual=0x0
Addendum: Me and the reporters here experienced this issue starting with gtk+ 3.11.5. From its changelog: "Theming: GTK+ now uses RGBA visuals by default"
Actually, GDK_RGBA=0 seems to solve all crashes with >=gtk+-3.11.5 for me. Can somebody explain what an application needs to compatible with GDK_RGBA=1?
Looking at the causing commit, there is a link to https://bugzilla.gnome.org/show_bug.cgi?id=630217 . It has a description of the problem and also mentions that the changes have been reverted for gtk+-3.11.6 because of https://bugzilla.gnome.org/show_bug.cgi?id=724067 and https://bugzilla.gnome.org/show_bug.cgi?id=723740 . Not the bug of this report in any case.
I also trapped into this bug indirectly after filling Emacs bug #20263: I run Emacs on development host under X Window as: emacs24 --daemon emacsclient -c & Next when I connect to Emacs as: $ ssh -Y user <at> localhost ssh$ emacsclient -c C-x C-c ssh$ exit or as: $ startx xterm -- `command -v Xnest` :1 -geometry 800x600 xnest$ emacsclient -c C-x C-c xnest$ exit Emacs daemon exited on exit shell command (but because special #ifdef code as shown above). Seems that Emacs only one true application that require this feature...
I just installed the latest emacs (GNU Emacs 25.0.50.1) and it exhibits the same problem.
This issue is present on the default elementary OS Freya installation which uses 3.4.15 version of Gtk. Any idea how to fix this?
You can start emacs with this on ubuntu 14.04 XLIB_SKIP_ARGB_VISUALS=1 emacs more details available here: http://elementaryos.stackexchange.com/questions/797/how-to-get-gnu-emacs-work-on-elementary-os
This problem exists still on Ubuntu 16.10, when used through X2Go and using Xfce as windowing environment. When Emacs is used locally, there is no problem. The problem did not occur on 16.04, so something has changed between 16.04 and 16.10.
This problem exists still on Fedora 25 when used through x2go. Fails with XFCE4 and MATE desktops. Works with a X11 connection via ssh. Starting with: XLIB_SKIP_ARGB_VISUALS=1 emacs does not change anything, it still crashes with: X protocol error: BadRequest (invalid request code or no such operation) on protocol request 131 When compiled with GTK, Emacs cannot recover from X disconnects. This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715 For details, see etc/PROBLEMS. Fatal error 6: Aborted Backtrace: emacs[0x50ac9c] emacs[0x4f114c] emacs[0x50ad43] emacs[0x4c0ea0] emacs[0x4c57f6] emacs[0x4c587b] /lib64/libX11.so.6(_XError+0x11d)[0x7f68b373cddd] /lib64/libX11.so.6(+0x40d07)[0x7f68b3739d07] /lib64/libX11.so.6(+0x40dc5)[0x7f68b3739dc5] /lib64/libX11.so.6(_XReply+0x238)[0x7f68b373acd8] /lib64/libX11.so.6(XQueryPointer+0x8e)[0x7f68b3730e6e] /lib64/libgdk-3.so.0(+0x56b5a)[0x7f68b5784b5a] /lib64/libgdk-3.so.0(+0x75695)[0x7f68b57a3695] /lib64/libgdk-3.so.0(gdk_window_get_device_position_double+0x10b)[0x7f68b5776e5b] /lib64/libgdk-3.so.0(gdk_window_get_device_position+0x2d)[0x7f68b5776f5d] /lib64/libgtk-3.so.0(+0x338a39)[0x7f68b5d5aa39] /lib64/libgtk-3.so.0(+0x338faf)[0x7f68b5d5afaf] /lib64/libgdk-3.so.0(+0x29e78)[0x7f68b5757e78] /lib64/libglib-2.0.so.0(+0x4a89d)[0x7f68b40a989d] /lib64/libglib-2.0.so.0(g_main_context_dispatch+0x162)[0x7f68b40a8e52] emacs[0x5e09a8] emacs[0x5a5cf7] emacs[0x422f33] emacs[0x4fd3d1] emacs[0x4fdf3d] emacs[0x4ffb84] emacs[0x564432] emacs[0x4f1614] emacs[0x5643d3] emacs[0x4f15d0] emacs[0x4f5dd7] emacs[0x4f6128] emacs[0x419d52] /lib64/libc.so.6(__libc_start_main+0xf1)[0x7f68abf4e401] emacs[0x41a79a] Aborted (core dumped)
I see the same error message when opening emacs with X11-forwarding. My client is Windows 10 Home Edition with Xming installed. I used putty to log in to the Manjaro server. OS of the server is Manjaro
I have same error. Similar condition with comment76. Use SecureCRT or Putty to login with x-11 forwarding. What's the solution for this? Help
As in comment 75, emacs in an X2go session on Fedora 26 still gets this error. X protocol error: BadRequest (invalid request code or no such operation) on protocol request 131 When compiled with GTK, Emacs cannot recover from X disconnects. This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715 For details, see etc/PROBLEMS. Fatal error 6: Aborted Backtrace: emacs[0x50abde] emacs[0x4f12f9] emacs[0x50ac83] emacs[0x4c0d90] emacs[0x4c50d9] emacs[0x4c515b] /lib64/libX11.so.6(_XError+0x11a)[0x7f2109eca9ba] /lib64/libX11.so.6(+0x418eb)[0x7f2109ec78eb] /lib64/libX11.so.6(+0x41995)[0x7f2109ec7995] /lib64/libX11.so.6(_XReply+0x240)[0x7f2109ec88f0] /lib64/libX11.so.6(XQueryPointer+0x8e)[0x7f2109ebe99e] /lib64/libgdk-3.so.0(+0x56e11)[0x7f210bf1be11] /lib64/libgdk-3.so.0(+0x72dd6)[0x7f210bf37dd6] /lib64/libgdk-3.so.0(gdk_window_get_device_position_double+0x114)[0x7f210bf0dc94] /lib64/libgdk-3.so.0(gdk_window_get_device_position+0x2d)[0x7f210bf0ddbd] /lib64/libgtk-3.so.0(+0x338db1)[0x7f210c4f3db1] /lib64/libgtk-3.so.0(+0x3392ef)[0x7f210c4f42ef] /lib64/libgdk-3.so.0(+0x29d50)[0x7f210beeed50] /lib64/libglib-2.0.so.0(+0x4acad)[0x7f210a835cad] /lib64/libglib-2.0.so.0(g_main_context_dispatch+0x157)[0x7f210a835247] emacs[0x5e1b30] emacs[0x5a7039] emacs[0x423560] emacs[0x4fd197] emacs[0x4fe050] emacs[0x4ffad4] emacs[0x5635e2] emacs[0x4f1714] emacs[0x563561] emacs[0x4f16ab] emacs[0x4f5f67] emacs[0x4f628a] emacs[0x41a09c] /lib64/libc.so.6(__libc_start_main+0xea)[0x7f210184950a] emacs[0x41ab8a] Aborted (core dumped)
I am also seeing this issue while using emacs editor on a SLES12.2 OS host: [SLES12.2 hds1fna2091 20180129_1537 ~]# emacs temp & [1] 79306 [SLES12.2 hds1fna2091 20180129_1537 ~]# Activating service name='org.gtk.vfs.Daemon' Successfully activated service 'org.gtk.vfs.Daemon' Activating service name='org.gnome.GConf' Successfully activated service 'org.gnome.GConf' (emacs-gtk:79314): Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed X protocol error: BadRequest (invalid request code or no such operation) on protocol request 131 When compiled with GTK, Emacs cannot recover from X disconnects. This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715 For details, see etc/PROBLEMS. Backtrace: /usr/bin/emacs-gtk[0x4f88bb] /usr/bin/emacs-gtk[0x4de48e] /usr/bin/emacs-gtk[0x4f8903] /usr/bin/emacs-gtk[0x4b374b] /usr/bin/emacs-gtk[0x4b57ec] /usr/bin/emacs-gtk[0x4b584d] /usr/lib64/libX11.so.6(_XError+0x12b)[0x7fd78a9692cb] /usr/lib64/libX11.so.6(+0x43367)[0x7fd78a966367] /usr/lib64/libX11.so.6(+0x43415)[0x7fd78a966415] /usr/lib64/libX11.so.6(_XReply+0x1e8)[0x7fd78a9672f8] /usr/lib64/libX11.so.6(XQueryPointer+0x55)[0x7fd78a95d825] ...
There is similar behavior using Windows 10 with PuTTY (X11 Forwarding) to run emacs on a Debian system. Any attempt to do anything (change size, click in, use a drop down, etc) with the emacs window results in the window closing, and this error: (emacs:23589): Gtk-CRITICAL **: gtk_window_set_mnemonics_visible: assertion 'GTK _IS_WINDOW (window)' failed X protocol error: BadRequest (invalid request code or no such operation) on prot ocol request 130 When compiled with GTK, Emacs cannot recover from X disconnects. This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715 For details, see etc/PROBLEMS. Fatal error 6: Aborted Backtrace: emacs[0x50b41c] emacs[0x4f17cc] emacs[0x50b4c3] emacs[0x4c14f0] emacs[0x4c5e26] emacs[0x4c5eab] /usr/lib/x86_64-linux-gnu/libX11.so.6(_XError+0x11d)[0x7fca2ecac22d] /usr/lib/x86_64-linux-gnu/libX11.so.6(+0x42157)[0x7fca2eca9157] /usr/lib/x86_64-linux-gnu/libX11.so.6(+0x42215)[0x7fca2eca9215] /usr/lib/x86_64-linux-gnu/libX11.so.6(_XReply+0x238)[0x7fca2ecaa128] /usr/lib/x86_64-linux-gnu/libX11.so.6(XQueryPointer+0x8e)[0x7fca2eca02be] /usr/lib/x86_64-linux-gnu/libgdk-3.so.0(+0x58841)[0x7fca30aee841] /usr/lib/x86_64-linux-gnu/libgdk-3.so.0(+0x74b76)[0x7fca30b0ab76] /usr/lib/x86_64-linux-gnu/libgdk-3.so.0(gdk_window_get_device_position_double+0x 114)[0x7fca30ae0684] /usr/lib/x86_64-linux-gnu/libgdk-3.so.0(gdk_window_get_device_position+0x2d)[0x7 fca30ae07ad] /usr/lib/x86_64-linux-gnu/libgtk-3.so.0(+0x33c8b1)[0x7fca310c98b1] /usr/lib/x86_64-linux-gnu/libgtk-3.so.0(+0x33cdef)[0x7fca310c9def] /usr/lib/x86_64-linux-gnu/libgdk-3.so.0(+0x2b770)[0x7fca30ac1770] /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4b853)[0x7fca2f417853] /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x155)[0x7fca2f41 6dd5] emacs[0x5df7a8] emacs[0x5a6b85] emacs[0x4fc87c] emacs[0x4fe68d] emacs[0x5002c4] emacs[0x564c22] emacs[0x4f1c94] emacs[0x564bc3] emacs[0x4f1c50] emacs[0x4f6477] emacs[0x4f67d8] emacs[0x419212] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7fca2a1faf2a] emacs[0x419c5a] Aborted
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/221.