undefined glXGetCurrentContext on EGL tracing

[okias]

How I understand the situation is following:

1. GTK wants to render context.
2. libepoxy starts query for symbol glXGetCurrentContext
3. because the GL library points to EGL, the symbol is missing
4. apitrace crashes due to the GTK app (epoxy) cannot find the symbol

A possible solution would be a variable to disable GLX or EGL at runtime.

Additional idea: Change order to prefer EGL in epoxy (which makes sense because EGL is more widespread these days).

$ apitrace trace -a egl gtk4-demo
apitrace: loaded into /usr/bin/apitrace
apitrace: unloaded from /usr/bin/apitrace
apitrace: loaded into /usr/bin/gtk4-demo
** Message: 02:06:00.252: For syntax highlighting, install the “highlight” program
apitrace: redirecting dlopen("libEGL.so.1", 0x1) from /lib/x86_64-linux-gnu/libepoxy.so.0
apitrace: tracing to /home/projects/collabora/mesa/gtk4-demo.trace
apitrace: warning: eglChooseConfig: unknown key 0x3339, interpreting value as int
apitrace: warning: eglChooseConfig: unknown key 0x3339, interpreting value as int
apitrace: redirecting dlopen("libGL.so.1", 0x1) from /lib/x86_64-linux-gnu/libepoxy.so.0
apitrace: attempting to read configuration file: /home/okias/.config/apitrace/gltrace.conf
apitrace: using configuration file: /home/okias/.config/apitrace/gltrace.conf
apitrace: config GL_VENDOR = 
apitrace: config GL_VERSION = 4.5
apitrace: config GL_EXTENSIONS = 
apitrace: config GL_NUM_EXTENSIONS = 0
apitrace: config GL_RENDERER = 
apitrace: config GL_SHADING_LANGUAGE_VERSION = 4.50
apitrace: config GL_MAX_TEXTURE_SIZE = 0
apitrace: config GL_MAJOR_VERSION = 4
apitrace: config GL_MINOR_VERSION = 5
apitrace: config GL_CONTEXT_PROFILE_MASK = 0x0
apitrace: config GL_CONTEXT_PROFILE_MASK = 0x0
apitrace: config GL_UNIFORM_BUFFER_OFFSET_ALIGNMENT = 32
apitrace: config GL_TEXTURE_BUFFER_OFFSET_ALIGNMENT = 16
apitrace: config GL_STORAGE_BUFFER_OFFSET_ALIGNMENT = 4
glXGetCurrentContext() not found: /usr/bin/../lib/x86_64-linux-gnu/apitrace/wrappers/egltrace.so: undefined symbol: glXGetCurrentContext
apitrace: warning: caught signal 6
apitrace: flushing trace
/usr/bin/../lib/x86_64-linux-gnu/apitrace/wrappers/egltrace.so+0x226300
/lib/x86_64-linux-gnu/libc.so.6+0x3bf8f: ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
/lib/x86_64-linux-gnu/libc.so.6: __pthread_kill_implementation+0x8accc: ./nptl/pthread_kill.c:44
/lib/x86_64-linux-gnu/libc.so.6: __GI_raise+0x11: ../sysdeps/posix/raise.c:26
/lib/x86_64-linux-gnu/libc.so.6: __GI_abort+0xd2: ./stdlib/abort.c:79
/lib/x86_64-linux-gnu/libepoxy.so.0: do_dlsym+0xc0fb0: ../src/dispatch_common.c:343
/lib/x86_64-linux-gnu/libepoxy.so.0: epoxy_glXGetCurrentContext_resolver+0xbecee: src/glx_generated_dispatch.c:3736
/lib/x86_64-linux-gnu/libepoxy.so.0: epoxy_glXGetCurrentContext_global_rewrite_ptr+0xbecee: src/glx_generated_dispatch.c:4270
/lib/x86_64-linux-gnu/libepoxy.so.0: epoxy_get_bootstrap_proc_address+0xc185d: ../src/dispatch_common.c:813
/lib/x86_64-linux-gnu/libepoxy.so.0: gl_single_resolver+0x64332: src/gl_generated_dispatch.c:75810
/lib/x86_64-linux-gnu/libepoxy.so.0: epoxy_glGetIntegerv_resolver+0x70ffe: src/gl_generated_dispatch.c:87733
/lib/x86_64-linux-gnu/libepoxy.so.0: epoxy_glGetIntegerv_global_rewrite_ptr+0x70ffe: src/gl_generated_dispatch.c:115489
/lib/x86_64-linux-gnu/libepoxy.so.0: epoxy_internal_has_gl_extension+0xc128a: ../src/dispatch_common.c:530
/lib/x86_64-linux-gnu/libepoxy.so.0: epoxy_internal_has_gl_extension+0xc128a: ../src/dispatch_common.c:519
/lib/x86_64-linux-gnu/libgtk-4.so.1: gdk_gl_context_make_current+0x21a
/lib/x86_64-linux-gnu/libgtk-4.so.1+0x4b7a23
/lib/x86_64-linux-gnu/libgtk-4.so.1+0x4ac48f
/lib/x86_64-linux-gnu/libgtk-4.so.1: gsk_renderer_realize+0x11d
/lib/x86_64-linux-gnu/libgtk-4.so.1: gsk_renderer_new_for_surface+0x9c
/lib/x86_64-linux-gnu/libgtk-4.so.1+0x31e6b7
/lib/x86_64-linux-gnu/libgtk-4.so.1+0xd3680
/lib/x86_64-linux-gnu/libgobject-2.0.so.0: g_closure_invoke+0x15f
/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x28d2c
/lib/x86_64-linux-gnu/libgobject-2.0.so.0: g_signal_emit_valist+0xf34
/lib/x86_64-linux-gnu/libgobject-2.0.so.0: g_signal_emit+0x8e
/lib/x86_64-linux-gnu/libgtk-4.so.1: gtk_widget_realize+0x6f
/lib/x86_64-linux-gnu/libgtk-4.so.1+0x323851
/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x165a8
/lib/x86_64-linux-gnu/libgobject-2.0.so.0: g_signal_emit_valist+0xefe
/lib/x86_64-linux-gnu/libgobject-2.0.so.0: g_signal_emit+0x8e
/lib/x86_64-linux-gnu/libgtk-4.so.1: gtk_widget_show+0xa0
/lib/x86_64-linux-gnu/libgtk-4.so.1: gtk_window_present_with_time+0xb4
gtk4-demo+0x6cf77
/lib/x86_64-linux-gnu/libgio-2.0.so.0+0x81b66
/lib/x86_64-linux-gnu/libgobject-2.0.so.0: g_closure_invoke+0x15f
/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x29075
/lib/x86_64-linux-gnu/libgobject-2.0.so.0: g_signal_emit_valist+0x76c
/lib/x86_64-linux-gnu/libgobject-2.0.so.0: g_signal_emit+0x8e
/lib/x86_64-linux-gnu/libgio-2.0.so.0+0xdafd2
/lib/x86_64-linux-gnu/libgio-2.0.so.0+0xdd309
/lib/x86_64-linux-gnu/libgio-2.0.so.0: g_application_run+0x145
gtk4-demo: main+0x204
/lib/x86_64-linux-gnu/libc.so.6: __libc_start_call_main+0x27189: ../sysdeps/nptl/libc_start_call_main.h:58
/lib/x86_64-linux-gnu/libc.so.6: __libc_start_main_impl+0x84: ../csu/libc-start.c:381
gtk4-demo: _start+0x20
?
apitrace: info: taking default action for signal 6

[Mis012]

I don't get how this issue was still not fixed...

[okias]

@Mis012 it's not usually visible, but since more than year passed, option to disable GLX at buildrun-time could be appropriate since it's getting into background.

[Mis012]

iirc I had to also build my own Gtk when I went that route last time, because otherwise it would complain that libepoxy doesn't support glx (which it didn't plan to use anyway)

in any case, having to build anything from source is ridiculous when this is clearly something that was claimed to have been solved

[Mis012]

actually, this does seem like a duplicate of #68

[Mis012]

so, somehow I have finally found a workaround...

ln -s /usr/lib64/apitrace/wrappers/egltrace.so libEGL.so.1
TRACE_LIBGL= LD_LIBRARY_PATH=. apitrace trace --api=egl <program>

[nikolaszimmermann]

I can confirm that apitrace -a egl is not usable for me, when the target application links against libepoxy.
Running e.g. apitrace trace --api=egl run-minibrowser --wpe --release:

Using Cog as MiniBrowser
apitrace: loaded into /host/home/nzimmermann/Software/GitRepositories/WebKit/WebKitBuild/Release/Tools/cog-prefix/src/cog-build/launcher/cog
Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal
apitrace: loaded into /host/home/nzimmermann/Software/GitRepositories/WebKit/WebKitBuild/Release/bin/WPENetworkProcess
Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal
apitrace: redirecting dlopen("libEGL.so.1", 0x1) from /lib/x86_64-linux-gnu/libepoxy.so.0
apitrace: tracing to /host/home/nzimmermann/Software/GitRepositories/WebKit/cog.1.trace
apitrace: warning: eglChooseConfig: unknown key 0x3339, interpreting value as int
apitrace: warning: eglChooseConfig: unknown key 0x3339, interpreting value as int
apitrace: redirecting dlopen("libGL.so.1", 0x1) from /lib/x86_64-linux-gnu/libepoxy.so.0
apitrace: attempting to read configuration file: /home/nzimmermann/.config/apitrace/gltrace.conf
glXGetCurrentContext() not found: /usr/bin/../lib/x86_64-linux-gnu/apitrace/wrappers/egltrace.so: undefined symbol: glXGetCurrentContext
apitrace: warning: caught signal 6

Despite many experimentation, I couldn't find any workaround, despite than patching libepoxy itself:

diff --git a/src/dispatch_common.c b/src/dispatch_common.c
index 153eb7c..5fcca10 100644
--- a/src/dispatch_common.c
+++ b/src/dispatch_common.c
@@ -809,7 +809,7 @@ epoxy_get_bootstrap_proc_address(const char *name)
     /* If we already have a library that links to libglapi loaded,
      * use that.
      */
-#if PLATFORM_HAS_GLX
+#if PLATFORM_HAS_GLX && !PLATFORM_HAS_EGL
     if (api.glx_handle && glXGetCurrentContext())
         return epoxy_gl_dlsym(name);
 #endif

[nikolaszimmermann]

This allows me to use apitrace -a egl and trace WPE WebKit, across multiple processes, just fine.

Some additional information from my investigations, that might be helpful to judge if the current way of calling 'glGetCurrentContext()'` is sane, on Wayland+EGL platforms.

The bug is not new, it was apparently fixed in apitrace/apitrace#380, a long time ago, in this way: dbfa4b2.
However, this commit got removed again upstream due to a regression in kwin (IIRC reverted by @ebassi).

Anyhow, I'm currently using a custom patched libepoxy build which allows me to use apitrace -- not sure what's the right way to fix upstream.