glPushDebugGroupKHR jumping at the wrong offset into the dispatch table

[lb90]

Epoxy reports that the GL_KHR_debug extension is supported, but when calling glPushDebugGroupKHR it actually jumps at the dispatch entry for glProgramUniformMatrix2x4fvEXT, which happens to ba unavailable on my system, and then the application crashes.

769         glPushDebugGroupKHR (GL_DEBUG_SOURCE_APPLICATION, 0, -1, message);
(gdb) s
epoxy_glPushDebugGroupKHR_dispatch_table_thunk (source=33354, id=0, length=-1, message=0x7ffdc2e189cb <__func__.0+1915> "Building command queue") at src/gl_generated_dispatch.c:51142
51142      0, // glProgramUniformMatrix2x4fvEXT
(gdb) n
Thread 1 received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb)

See https://gitlab.gnome.org/GNOME/gtk/-/issues/5128

• AMD driver
• Windows 10 21H2
• MSYS2

[ebassi]

This looks like a GL driver issue.

Actually: did you create a debug GL context? You need a debug context in order to push a debug group.

[lb90]

I have updated the AMD driver package, but to no avail.

However I experience the same issue in calls to glDeleteProgram, see https://gitlab.gnome.org/GNOME/gtk/-/issues/5129. And on another device with Intel UHD integrated graphics and NVIDIA GeForce MX discrete graphics I get the same crash (tested by running on both the graphics devices).

I am starting to wonder if this ain't something similar to what's mentioned in https://github.com/anholt/libepoxy/pull/265? I'll try to dig further...

Thank you!

[lb90]

Ok, I have some updates:

glDeleteProgram is called after setting the WGL context to NULL. This cannot be done, because the addresses returned by wglGetProcAddress are subject to the active WGL context. In particular, for a NULL WGL context, wglGetProcAddress always returns NULL.

This is also explained in https://github.com/anholt/libepoxy/blob/1.5.10/README.md#known-issues-when-running-on-windows

So this issue should be taken back to GTK. Not sure though if libepoxy could be made better, like e.g fail with a message