After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 738873 - wayland backend aborts entire program if XDG_RUNTIME_DIR unset
wayland backend aborts entire program if XDG_RUNTIME_DIR unset
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Wayland
unspecified
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2014-10-20 14:57 UTC by Allison Karlitskaya (desrt)
Modified: 2014-10-21 12:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
wayland: don't init if XDG_RUNTIME_DIR missing (1.34 KB, patch)
2014-10-20 21:43 UTC, Allison Karlitskaya (desrt)
committed Details | Review

Description Allison Karlitskaya (desrt) 2014-10-20 14:57:58 UTC
We follow the xdg spec and implement a fallback for XDG_RUNTIME_DIR (in ~/.cache) if it is unset.

Unfortunately, wayland logs an error in this case.  Our wayland log handler then does this:

static void
log_handler(const char *format, va_list args)
{
  g_logv (G_LOG_DOMAIN, G_LOG_LEVEL_ERROR, format, args);
}


which is fatal.


This happens any time someone tries to initialise wayland with XDG_RUNTIME_DIR unset.  That can happen if DISPLAY is unset, for example (which will cause the X11 init to fail, moving on to the next backend, which is wayland).

So we've now gone from a place where unset DISPLAY and XDG_RUNTIME_DIR used to cause gtk_init() to fail to a place where it causes the entire program to abort, simply because we happen to be trying wayland as a second effort.

We can fix this in some ways:

 1) only try the wayland backend if GDK_BACKEND=wayland explicitly

 2) fix libwayland not to throw an error in this case (and maybe fallback
    to ~/.cache/ in the way the spec suggests)

 3) avoid bringing up the wayland backend if XDG_RUNTIME_DIR is unset to
    avoid the certain abort that will follow

 4) log wayland messages in a less-fatal way

I'm in favour of 2.  If that's not on the table, I'd consider 3 to be the best option.
Comment 1 Allison Karlitskaya (desrt) 2014-10-20 21:43:47 UTC
Created attachment 288986 [details] [review]
wayland: don't init if XDG_RUNTIME_DIR missing

wayland doesn't strictly follow the XDG_RUNTIME_DIR spec by falling back
to another directory in case the runtime dir is not properly set.

When this variable is unset, wayland will log an error to us, which we
treat as fatal, aborting the entire program.

Skip ourselves all the trouble and don't try to bring up the wayland
backend when we know it will fail in this way.
Comment 2 Matthias Clasen 2014-10-21 03:20:42 UTC
Review of attachment 288986 [details] [review]:

Looks like an ok workaround
Comment 3 Allison Karlitskaya (desrt) 2014-10-21 12:12:43 UTC
Attachment 288986 [details] pushed as 6d7f5d4 - wayland: don't init if XDG_RUNTIME_DIR missing
Comment 4 Allison Karlitskaya (desrt) 2014-10-21 12:15:50 UTC
Pushed (and backported).
Comment 5 Daniel Stone 2014-10-21 12:25:40 UTC
(In reply to comment #0)
> We follow the xdg spec and implement a fallback for XDG_RUNTIME_DIR (in
> ~/.cache) if it is unset.

Unfortunately, XDG_RUNTIME_DIR is the only directory the spec doesn't mandate a specific fallback for; instead, it just says 'a replacement directory' with specified capabilities. Is ~/.cache widely accepted as the best fallback? And, if so, should that perhaps be encoded in the spec?