Bug 275598 – Stack corruption crash in _glXLookupVendorByName

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKitGTK

[John Ralls]

We just resolved (by working around) a WebKitGtk crash in GnuCash, see https://bugs.gnucash.org/show_bug.cgi?id=799301 for the gory details. Our flatpak build configuration can be found at https://github.com/flathub/org.gnucash.gnucash. The short summary is
*** stack smashing detected ***: terminated

Thread 1 "gnucash" received signal SIGABRT, Aborted.
0x00007ffff65abe14 in __pthread_kill_implementation () from /usr/lib/x86_64-linux-gnu/libc.so.6

(gdb) bt full
#0  0x00007ffff65abe14 in __pthread_kill_implementation () at /usr/lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff6559dce in raise () at /usr/lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff654183f in abort () at /usr/lib/x86_64-linux-gnu/libc.so.6
#3  0x00007ffff6542710 in __libc_message.cold () at /usr/lib/x86_64-linux-gnu/libc.so.6
#4  0x00007ffff66400a9 in __fortify_fail () at /usr/lib/x86_64-linux-gnu/libc.so.6
#5  0x00007ffff6641364 in __stack_chk_fail () at /usr/lib/x86_64-linux-gnu/libc.so.6
#6  0x00007ffff65a581d in _dlerror_run () at /usr/lib/x86_64-linux-gnu/libc.so.6
#7  0x00007ffff65a5cbf in dlopen () at /usr/lib/x86_64-linux-gnu/libc.so.6
#8  0x00007fffeb6ff2b8 in __glXLookupVendorByName () at /usr/lib/x86_64-linux-gnu/libGLX.so.0
#9  0x00007fffeb701b2d in __glXLookupVendorByScreen () at /usr/lib/x86_64-linux-gnu/libGLX.so.0
#10 0x00007fffeb7028af in glXQueryServerString () at /usr/lib/x86_64-linux-gnu/libGLX.so.0
#11 0x00007ffff525b343 in epoxy_glx_version () at /usr/lib/x86_64-linux-gnu/libepoxy.so.0
#12 0x00007ffff5bb60a6 in gdk_x11_screen_init_gl () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#13 0x00007ffff5bb683a in gdk_x11_window_create_gl_context () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#14 0x00007ffff5b66162 in gdk_window_get_paint_gl_context () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#15 0x00007ffff5b6624e in gdk_window_create_gl_context () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#16 0x00007fffef42c94d in std::once_flag::_Prepare_execution::_Prepare_execution<std::call_once<WebKit::gtkCanUseHardwareAcceleration()::$_0>(std::once_flag&, WebKit::gtkCanUseHardwareAcceleration()::$_0&&)::{lambda()#1}>(WebKit::gtkCanUseHardwareAcceleration()::$_0&)::{lambda()#1}::__invoke() () at /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.1.so.0

The user was able to work around the crash by setting WEBKIT_DISABLE_COMPOSITING_MODE=1.

[Michael Catanzaro]

I'm going to close this because there's surely not anything WebKit can do if just querying the GL version string causes a crash.

First step here is to get a better backtrace. What we see above is not sufficient due to missing debuginfo. I'd want to see line numbers at least to know where exactly it is crashing. We have instructions here: https://handbook.gnome.org/issues/stack-traces.html

Once you've got a better backtrace, you can report to either the GLX provider (probably glvnd) or else the libc (probably glibc) depending on what the better backtrace reveals. What you've posted here *really* looks like a bug in dlopen() itself. That seems quite unlikely, but it's sure what it looks like.