GNOME Bugzilla – Bug 737282
RFE: gdk/x11: callback on X11 error
Last modified: 2018-04-15 00:37:05 UTC
Cloning since I'm unable to just reopen bug 737205. gdk/x11 calls _exit(1) in the handlers set by both XSetErrorHandler and XSetIOErrorHandler. This is probably fine for applications that expect to die when the display is no longer accessible, but terrible for applications that expect to do any cleanup of their own, or that attempt to continue without X. To answer the question in bug 737205 concerning what has changed, anaconda now cares a lot more about handling different exit scenarios due to the recent ipmi integration. Right now it is impossible for us to do anything if the X server crashes. Calling exit(1), as suggested, would at least be better, since that way we would be able to run our own atexit code, but ideally we would be able to register a callback that could be run within an X11 error handler. +++ This bug was initially created as a clone of Bug #737205 +++ Anaconda is a program that wants to run atexit handlers; it can get disconnected from X if VNC crashes. Note that both libX11 and Qt call exit() and not _exit(), so this changes GTK+ to match.
To add on to this since I've been trying to deal with the same problem: If GDK is using Xlib, the application can set its own handler with XSetIOErrorHandler, after calling gtk_init. It should be harmless, I think, for that handler to simply call exit (or _exit if you prefer) when it's done. Alternatively you could save GDK's handler and call it after doing your own cleanup. Obviously this is messy; it'd be better for GDK to provide a backend-independent way for the application to run cleanup functions when the display connection is broken. (Granted, XSetIOErrorHandler is not a great API to begin with; it'd be better if there were a way for applications to fully recover from losing a GdkDisplay. But as far as I know there's no way to do that with Xlib.) For Win32, it looks like the analagous situation would be receiving a WM_ENDSESSION message?
In the Xlib case, though, I don't think it's possible to avoid a period, however short, when the default, _exiting error handlers are set. When programming in just Xlib the default error handlers can be avoided just by calling XSetErrorHandler and XSetIOErrorHandler before connecting to the display, but as far as I know there's no way to order the calls like that in Gdk.
Not saying this is great, but you _can_ catch the warning message in our XIOErrorHandler: #include <string.h> #include <gtk/gtk.h> static void log_func (const gchar *domain, GLogLevelFlags level, const gchar *message, gpointer data) { if (strstr (message, "Fatal IO error")) printf ("caught it!\n"); } int main (int argc, char *argv[]) { GtkWidget *w; gtk_init (NULL, NULL); g_log_set_handler ("Gdk", G_LOG_LEVEL_WARNING, log_func, NULL); w = gtk_window_new (GTK_WINDOW_TOPLEVEL); gtk_widget_show (w); gtk_main (); return 0; }
I don't guess you'd consider making g_log_set_handler introspectable?
(In reply to comment #4) > I don't guess you'd consider making g_log_set_handler introspectable? set_handler() is, sadly, not introspectable, and won't be — it lacks a GDestroyNotify for the function data. we could add a g_log_set_handler_full() that took a GDestroyNotify, and which would be introspectable. the GLogLevelFlags enumeration may have some other issues, but at least it's recognised as a bitfield.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new