Hi, thanks for maintaining steam-for-linux. I have what looks like an AMD/RADV counterpart to issue #9780 (the one that got a Beta channel workaround for the NVIDIA side). I wanted to share what I'm seeing in case it's useful and in case there's interest in a similar mitigation for the AMD path. I might be missing something obvious, so please feel free to point me at the right thread if this is already covered somewhere I didn't find.
The short version is that turning on GPUAccelWebViewsV3 immediately crash loops the steamwebhelper on my machine. Setting it back to 0 makes Steam stable again but Big Picture is noticeably laggy because the CEF UI ends up software rendered. I've spent a while trying to find a way to keep GPUAccelWebViewsV3=1 without the crash, including a few env vars and launch flags, and so far nothing I can do as a user gets me to a stable state with GPU acceleration on. I'd love to be able to use the smoother UI eventually, and I'm hoping this report helps narrow down what's happening.
My setup
My machine is a desktop with an AMD Radeon RX 7600 XT, which Mesa reports as RADV NAVI33. I'm on Fedora 42 with kernel 6.19.x, Mesa 25.1.9 (mesa-vulkan-drivers-25.1.9-1.fc42), and the session is KDE Plasma 6 on native Wayland under SDDM. Steam is the native RPM (steam-1.0.0.85-6.fc42, currently on the Beta channel, build 1780352834). The CEF version in cef_log.txt is Chrome 126.0.6478.183. There's also a Ryzen 7000 series iGPU present, but it isn't used for display, and I do not pass DRI_PRIME, so this isn't a hybrid GPU steering scenario.
How to reproduce
On my end I just edit ~/.steam/registry.vdf and flip the value:
It reproduces whether I add -bigpicture or not. The Steam UI never reaches a usable state. systemd-coredump catches a fresh core every time the webhelper respawns.
Crash signature
The signal is SIGSEGV. The crashing thread's instruction pointer is NULL, so it looks like a jump through a function pointer that wasn't initialized. The other registers are identical on every run I've captured, which is what made me think this is a deterministic codepath rather than memory corruption:
The backtrace on the crashing thread is eight frames inside libcef.so before start_thread, with no resolvable symbols for me to share, but the offsets line up across runs once you adjust for ASLR:
#0 0x0000000000000000 in ?? (NULL call)
#1 0x000056044aaab27b in ?? (libcef.so .text)
#2 0x000056044aaab477 in ??
#3 0x000056044aaabe06 in ??
#4 0x000056044aaae6cb in ??
#5 0x000056044ae2359a in ??
#6 0x000056044ae20ca9 in ??
#7 0x000056044ae214ab in ??
#8 0x000056044ae26f78 in ??
#9 start_thread () from libc.so.6
[#10](/issue/ValveSoftware/steam-for-linux/10) __clone3 () from libc.so.6
On a separate thread in the same dump, mesa is mid initialization through the GLX/DRI3 path:
So the Chromium GPU process is going through X11 GLX even though the session is native Wayland, and something in the CEF initialization path crashes at the same moment the GLX worker is setting up the DRI3 screen.
Things I tried that didn't help
I tried Steam Stable as well as Beta and got the same crash with the same fingerprint. I tried passing -no-cef-sandbox on the steam command line, but it doesn't seem to make it into the webhelper's argv, so the crash is unchanged. I tried setting OZONE_PLATFORM_HINT=wayland in the environment before launching Steam, which I was hoping would steer Chromium onto EGL and away from libGLX_mesa, but the webhelper still loaded libGLX_mesa.so and crashed the same way. I tried H264HWAccel=0 in the registry, no effect. I tried wrapping the whole Steam session in gamescope so the UI runs inside a fullscreen Wayland window, but the lag stays because the bottleneck appears to be the software CEF renderer itself rather than the compositor.
A partial finding that might be informative
The one workaround that moves the needle is LIBGL_DRI3_DISABLE=1:
LIBGL_DRI3_DISABLE=1 /usr/bin/steam -bigpicture
With that env var set, Mesa falls back to DRI2, GLX initialization actually succeeds, CCompositorGLThread::CreateOutputWindow logs that it created the window in OpenGL mode at 2560x1600, and the cef_log shows Loaded GL 4.6 cleanly. Then roughly one second later, the same NULL function pointer crash fires from a different callsite in CEF. The register fingerprint (rdx=0x20de, rsi=0x3600003, r10=0x3, r12=0x2) is identical to the GLX init crash, which makes me suspect the underlying bug isn't specifically in the DRI3 path. It feels more like there's a CEF code path that calls into something the AMD/Mesa stack hands back as null on this combination, and DRI3 is just one of the callsites that gets there first. I'm not certain about that interpretation, though, and I'd defer to whoever is more familiar with the CEF GPU initialization sequence.
What I'm hoping for
For now I'm running with GPUAccelWebViewsV3=0 and accepting the lag, which keeps Steam stable and lets everything else work fine (game launches, gamescope HDR, Proton, controllers, all good). What I'd really love is the same kind of Beta channel mitigation that shipped for NVIDIA in #9780, applied to the AMD/RADV path. If that isn't feasible, even pointers about which Chromium flags I could try to inject through a steamwebhelper wrapper would be helpful, although I understand that's a fragile thing to maintain across client updates.
Related issues I checked
I tried not to file a duplicate. The ones that came closest were #9780 (NVIDIA, same class of bug, has the Beta mitigation already), #12417 (RADV NAVI33 but as an eGPU, closed as a duplicate of #9383 which is about DRI_PRIME=1 hybrid steering), #12973 (AMD but crashes after a game launches, different signal), #11610 (AMD but during gameplay with different log lines), and #13151 (NVIDIA Wayland with the setting defaulting to OFF, which is roughly the opposite of what's happening here). None of them seem to cover this exact combination of plain discrete RDNA3, Mesa 25.x, and an immediate crash at Steam UI startup, but if any of them is actually the right home for this please let me know and I'll move the details over.
I'm happy to provide the actual core dumps, full thread backtraces, or test anything you'd like me to try in a Beta build. Thanks again for taking the time to look at this.
Hi, thanks for maintaining steam-for-linux. I have what looks like an AMD/RADV counterpart to issue #9780 (the one that got a Beta channel workaround for the NVIDIA side). I wanted to share what I'm seeing in case it's useful and in case there's interest in a similar mitigation for the AMD path. I might be missing something obvious, so please feel free to point me at the right thread if this is already covered somewhere I didn't find.
The short version is that turning on
GPUAccelWebViewsV3immediately crash loops the steamwebhelper on my machine. Setting it back to 0 makes Steam stable again but Big Picture is noticeably laggy because the CEF UI ends up software rendered. I've spent a while trying to find a way to keepGPUAccelWebViewsV3=1without the crash, including a few env vars and launch flags, and so far nothing I can do as a user gets me to a stable state with GPU acceleration on. I'd love to be able to use the smoother UI eventually, and I'm hoping this report helps narrow down what's happening.My setup
My machine is a desktop with an AMD Radeon RX 7600 XT, which Mesa reports as RADV NAVI33. I'm on Fedora 42 with kernel 6.19.x, Mesa 25.1.9 (
mesa-vulkan-drivers-25.1.9-1.fc42), and the session is KDE Plasma 6 on native Wayland under SDDM. Steam is the native RPM (steam-1.0.0.85-6.fc42, currently on the Beta channel, build1780352834). The CEF version incef_log.txtis Chrome126.0.6478.183. There's also a Ryzen 7000 series iGPU present, but it isn't used for display, and I do not passDRI_PRIME, so this isn't a hybrid GPU steering scenario.How to reproduce
On my end I just edit
~/.steam/registry.vdfand flip the value:Then I clear caches for a clean run:
It reproduces whether I add
-bigpictureor not. The Steam UI never reaches a usable state. systemd-coredump catches a fresh core every time the webhelper respawns.Crash signature
The signal is
SIGSEGV. The crashing thread's instruction pointer isNULL, so it looks like a jump through a function pointer that wasn't initialized. The other registers are identical on every run I've captured, which is what made me think this is a deterministic codepath rather than memory corruption:The backtrace on the crashing thread is eight frames inside
libcef.sobeforestart_thread, with no resolvable symbols for me to share, but the offsets line up across runs once you adjust for ASLR:On a separate thread in the same dump, mesa is mid initialization through the GLX/DRI3 path:
So the Chromium GPU process is going through X11 GLX even though the session is native Wayland, and something in the CEF initialization path crashes at the same moment the GLX worker is setting up the DRI3 screen.
Things I tried that didn't help
I tried Steam Stable as well as Beta and got the same crash with the same fingerprint. I tried passing
-no-cef-sandboxon the steam command line, but it doesn't seem to make it into the webhelper's argv, so the crash is unchanged. I tried settingOZONE_PLATFORM_HINT=waylandin the environment before launching Steam, which I was hoping would steer Chromium onto EGL and away fromlibGLX_mesa, but the webhelper still loadedlibGLX_mesa.soand crashed the same way. I triedH264HWAccel=0in the registry, no effect. I tried wrapping the whole Steam session in gamescope so the UI runs inside a fullscreen Wayland window, but the lag stays because the bottleneck appears to be the software CEF renderer itself rather than the compositor.A partial finding that might be informative
The one workaround that moves the needle is
LIBGL_DRI3_DISABLE=1:With that env var set, Mesa falls back to DRI2, GLX initialization actually succeeds,
CCompositorGLThread::CreateOutputWindowlogs that it created the window in OpenGL mode at 2560x1600, and the cef_log showsLoaded GL 4.6cleanly. Then roughly one second later, the same NULL function pointer crash fires from a different callsite in CEF. The register fingerprint (rdx=0x20de,rsi=0x3600003,r10=0x3,r12=0x2) is identical to the GLX init crash, which makes me suspect the underlying bug isn't specifically in the DRI3 path. It feels more like there's a CEF code path that calls into something the AMD/Mesa stack hands back as null on this combination, and DRI3 is just one of the callsites that gets there first. I'm not certain about that interpretation, though, and I'd defer to whoever is more familiar with the CEF GPU initialization sequence.What I'm hoping for
For now I'm running with
GPUAccelWebViewsV3=0and accepting the lag, which keeps Steam stable and lets everything else work fine (game launches, gamescope HDR, Proton, controllers, all good). What I'd really love is the same kind of Beta channel mitigation that shipped for NVIDIA in #9780, applied to the AMD/RADV path. If that isn't feasible, even pointers about which Chromium flags I could try to inject through a steamwebhelper wrapper would be helpful, although I understand that's a fragile thing to maintain across client updates.Related issues I checked
I tried not to file a duplicate. The ones that came closest were #9780 (NVIDIA, same class of bug, has the Beta mitigation already), #12417 (RADV NAVI33 but as an eGPU, closed as a duplicate of #9383 which is about
DRI_PRIME=1hybrid steering), #12973 (AMD but crashes after a game launches, different signal), #11610 (AMD but during gameplay with different log lines), and #13151 (NVIDIA Wayland with the setting defaulting to OFF, which is roughly the opposite of what's happening here). None of them seem to cover this exact combination of plain discrete RDNA3, Mesa 25.x, and an immediate crash at Steam UI startup, but if any of them is actually the right home for this please let me know and I'll move the details over.I'm happy to provide the actual core dumps, full thread backtraces, or test anything you'd like me to try in a Beta build. Thanks again for taking the time to look at this.