"Couldn't find current GLX or EGL context.\n" exits GNOME Games

[Kekun]

When running a game in GNOME Games in some ancient machine, the application quits with this message on stderr: "Couldn't find current GLX or EGL context.". The machine still has a powerful enough GPU (i915 driver) to run gnome-shell and power totem's clutter-gtk video display.

The error message was found in epoxy_get_proc_address().

I would like Games (which uses GtkGLArea) to be able to recover from this error by using a software rendering method, which implies for libepoxy to transmit its errors.

[nwnk]

I would like Games (which uses GtkGLArea) to be able to recover from this error by using a software rendering method, which implies for libepoxy to transmit its errors.

I would like it to not have the error in the first place. Can you be a bit more specific about how to reproduce this? What game are you trying to run? What version? What GPU in specific is this?

[hadess]

I still had access to this machine yesterday, but I don't anymore. The machine should get back to me in a number of weeks, it's part of the European GNOME events box.

@bastianilso might be able to help in the meanwhile.

Can you be a bit more specific about how to reproduce this?

The application using GTK+ 3's GtkGLArea will simply exit when a widget is instantiated.

What game are you trying to run?

Any supported by the shipped libretro cores, using GNOME Games' stable or nightly Flatpaks.

[anholt]

It's the responsibility of the application to create the GLX or EGL context before calling into libepoxy. This error is what you'd get if you'd failed to do so -- are you sure games isn't just failing to create its context and then calling libepoxy anyway?

[hadess]

It's the responsibility of the application to create the GLX or EGL context before calling into libepoxy. This error is what you'd get if you'd failed to do so -- are you sure games isn't just failing to create its context and then calling libepoxy anyway?

The application simply uses GtkGLArea, which doesn't have a failure path. So it's possible that GTK+ is calling out to libepoxy without doing any checks, but looking at the GTK+/GDK code, and without access to the machine on which I reproduced this problem, I find it unlikely.

[ebassi]

GtkGLArea has a failure path: if GtkGLArea.create_context() fails then GtkGLArea.render() is not called at all. The context creation is also dependent on the ability of GDK to have access to an OpenGL or OpenGL ES implementation.

[hadess]

I didn't say it couldn't fail, merely that it didn't have a way to report that error to the caller. And even if the caller is doing something wrong, why is libepoxy exiting the application instead of asserting, making it impossible to pinpoint the culprit?

[ebassi]

Of course GLArea can report the error to the caller:

  /* we need to ensure that the GdkGLContext is set before calling GL API */
  gtk_gl_area_make_current (GTK_GL_AREA (self->gl_drawing_area));

  /* if the GtkGLArea is in an error state we don't do anything */
  if (gtk_gl_area_get_error (GTK_GL_AREA (self->gl_drawing_area)) != NULL)
    return;

This is how, typically, you check before using GL with GtkGLArea.

why is libepoxy exiting the application instead of asserting, making it impossible to pinpoint the culprit?

libepoxy's behaviour is to abort() immediately as soon as the internal state is invalid — e.g. if you called a GL API that you don't have access to; so pointing GDB at the program should make it immediately clear as to what happened.

Without having access to a stack trace there's not much we can do, outside of saying that Games is using some GL functionality without checking if it can first.

[nwnk]

libepoxy's behaviour is to abort() immediately as soon as the internal state is invalid

... except this one place, where we call errx() instead. See #166.

[nwnk]

I've had no luck trying to reproduce this with a flatpak. Is there something already in Fedora that might trigger this? Can someone still experiencing it try again with git master and see if there's a more useful backtrace?

[hadess]

I still don't have access to the machine. It only happened on a machine with a ~10-year old Intel graphics card. I'll update this bug as soon as I get access to it again.

[seijikun]

I can reproduce this on Archlinux with a small game I wrote using SDL2. The OpenGL-Context creation works without problems. After the context is created, I check that it exists. If it does not - I exit the game. This is the code (a bit shortened):

assertSDL(SDL_Init(SDL_INIT_VIDEO | SDL_INIT_EVENTS));
window->init(); # window is a small wrapper calling SDL_CreateWindow(...)

# Setup a couple of OpenGL options
assertSDL(SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 4));
assertSDL(SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0));
assertSDL(SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_CORE));
assertSDL(SDL_GL_SetAttribute(SDL_GL_MULTISAMPLEBUFFERS, 1));
assertSDL(SDL_GL_SetAttribute(SDL_GL_MULTISAMPLESAMPLES, 4));
assertSDL(SDL_GL_SetAttribute(SDL_GL_CONTEXT_FLAGS, SDL_GL_CONTEXT_DEBUG_FLAG);

glContext = SDL_GL_CreateContext(window->getSDLWindow());
assertNotNull(glContext, "Creating GL context failed");
assertSDL(SDL_GL_SetSwapInterval(1));

# The following line crashes the program with the mentioned error message
if(epoxy_has_gl_extension("GL_ARB_debug_output")) {
    glEnable(GL_DEBUG_OUTPUT);
    glDebugMessageCallback(&OpenGLLoggerSource::handleOpenGLLogMessage, nullptr);
}

Simply removing the whole if block involving the epoxy_has_gl_extension("GL_ARB_debug_output") fixes the issue and everything works as expected.

My other machines do not show this error, despite having the same version of libepoxy. Gentoo: libepoxy - 1.5.1 [works] Archlinux: libepoxy - 1.5.1-1 [does not work]

[ebassi]

Does SDL_GL_CreateContext() also make the context current?

epoxy_has_gl_extension() amounts to a version check — i.e. glGetString(GL_VERSION) — and either a glGetString(GL_EXTENSIONS) or glGetStringi(GL_EXTENSIONS) with an index.

Does calling glGetString(GL_VERSION) explicitly work?

[seijikun]

Yes. The function documentation states:

Use this function to create an OpenGL context for use with an OpenGL window, and make it current. 

[ebassi]

@seijikun Thanks. Can you try with libepoxy from master?

[hadess]

@Kekun can you try with libepoxy from master?

He doesn't have access to the machine (and neither do I). And it was me filing this bug with his account while at a libre software meeting.

[ebassi]

Argh, that wasn't for @Kekun, sorry…

[seijikun]

If you also wanted me to test: The problem is gone with master.

[nwnk]

Fixed in 1.5.2.