Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Kekun opened this issue Mar 24, 2018 · 18 comments
Closed

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

Kekun opened this issue Mar 24, 2018 · 18 comments

Comments

@Kekun
Copy link

Kekun commented Mar 24, 2018

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
Copy link
Collaborator

nwnk commented Apr 9, 2018

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
Copy link

hadess commented Apr 10, 2018

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
Copy link
Owner

anholt commented Apr 10, 2018

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
Copy link

hadess commented Apr 10, 2018

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
Copy link
Collaborator

ebassi commented Apr 10, 2018

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
Copy link

hadess commented Apr 10, 2018

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
Copy link
Collaborator

ebassi commented Apr 10, 2018

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
Copy link
Collaborator

nwnk commented Apr 12, 2018

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
Copy link
Collaborator

nwnk commented May 1, 2018

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
Copy link

hadess commented May 1, 2018

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
Copy link

seijikun commented May 10, 2018

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
Copy link
Collaborator

ebassi commented May 10, 2018

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
Copy link

Yes. The function documentation states:

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

@ebassi
Copy link
Collaborator

ebassi commented May 10, 2018

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

@hadess
Copy link

hadess commented May 10, 2018

@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
Copy link
Collaborator

ebassi commented May 10, 2018

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

@seijikun
Copy link

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

@nwnk
Copy link
Collaborator

nwnk commented May 21, 2018

Fixed in 1.5.2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants