Possible incompatibility between libOpenGL.so and Xorg causing Xorg to crash on boot

[Ernest1338]

Hello,
Basic info:

• OS: Manjaro Linux KDE
• Kernel: 5.11.18-1-MANJARO
• GPU: Radeon R9 380 with AMDGPU drivers

The issue first appeared when I updated my system and after rebooting I noticed that Xorg has crashed. After some diagnostic I found that the libepoxy update was to blame for this. After discussing this issue with libepoxy maintainers (anholt/libepoxy#252) we ended up on suspecting that libglvnd could be the issue.

Here is the Xorg log of one of the crashes:
Xorg.0.log

This is the suspicious line from this log file:

[ 5840.986] (EE) AMDGPU(0): glGetString() returned NULL, your GL is broken

Also, here is the link to Manjaro forum discussing the issue: https://forum.manjaro.org/t/upgrading-libepoxy-from-1-5-5-to-1-5-7-results-in-xorg-crashing-on-boot/66195

[aaronp24]

Is libepoxy calling glGetString without a current context?

[ya-isakov]

libepoxy is only a library loader/dlsym dispatcher. Xorg is making EGL context here https://cgit.freedesktop.org/xorg/xserver/tree/glamor/glamor_egl.c?h=xorg-server-1.20.11#n1012, but fails here https://cgit.freedesktop.org/xorg/xserver/tree/glamor/glamor_egl.c?h=xorg-server-1.20.11#n1019

[ya-isakov]

Also, I'm a little bit surprised, that libGL.so is working (this is the only change in libepoxy, which breaks glGetString(GL_VENDOR) - libOpenGL.so is used instead of libGL.so)

[kbrenneman]

Are libGL.so and libEGL.so also from the same build of libglvnd?

[kbrenneman]

Also, try setting this environment variable before running X:

__GLVND_APP_ERROR_CHECKING=1

That'll tell libglvnd to print an error message and abort if a GL function is called without a current context. Normally, it'll just silently ignore such calls.

[Ernest1338]

This is the output of pkgfile for both of them:

• libGL.so

extra/libglvnd
community/cuda-tools
community/teamspeak3
multilib/lib32-libglvnd

• libEGL.so

extra/chromium
extra/libglvnd
extra/tuxedo-control-center
community/brave
community/brave-beta
community/discord
community/electron
community/electron10
community/electron11
community/electron8
community/electron9
community/ledger-live-bin
community/onlyoffice-desktopeditors
community/opera
community/signal-desktop
community/vivaldi
multilib/lib32-libglvnd

So I assume that, yes, both of them are provided by the libglvnd package from the manjaro repo.

[Ernest1338]

This is the Xorg log when I started it from TTY using this command:

__GLVND_APP_ERROR_CHECKING=1 startx

Xorg.1.log

[kbrenneman]

That looks like it doesn't have a current context, but I need the output on stderr to confirm, since that's where libglvnd will print the error message.

[Ernest1338]

I'm not sure if that is what you meant but I used this command:

__GLVND_APP_ERROR_CHECKING=1 startx 2>stderr_output.txt

and this is the result:
stderr_output.txt

[kbrenneman]

Yeah, that's it. And that confirms that glGetString is being called without a current context.

If all of the libraries are from libglvnd (and weren't overwritten by a driver or something), then that eglMakeCurrent call isn't setting a current context for some reason. I don't see a way that would happen just from reading the code, though. Your best bet might be to step through it in a debugger and see where it goes.

[ya-isakov]

@kbrenneman I posted my thought, why it could be, in original bug:
- Xorg is loading libGL.so, for GLX extension
- Xorg is using libepoxy for EGL init, and making context, which is set in loaded libGL.so
- Xorg is using libepoxy for glGetString, which is loading libOpenGL.so, essentially losing context, which is set in libGL.so?

Do you think, that this could be a cause?

[kbrenneman]

Nothing in libOpenGL.so can lose the current context. The current context for a thread changes only when you call eglMakeCurrent, glXMakeCurrent, or glXMakeContextCurrent.

It also doesn't matter which library an OpenGL function comes from. You can get glGetString from libGL.so, libOpenGL.so, libGLES*.so, or from egl/glXGetProcAddress, and they'll all be identical (again, assuming you don't have mismatched libraries). If there's a current GLX context, then the function gets dispatched to a GLX vendor library. If there's a current EGL context, then it gets dispatched to an EGL vendor library.

[Ernest1338]

The offending commit (in libepoxy repo) has been reverted, so I assume this will be fixed after I get an update from the manjaro repo.