Additionally, I've been having similar issues where after launching some games when Steam does load, the client silently (and regularly) crashes with the backtrace pointing to libSDL3.so every time. It doesn't happen immediately after the game launches, usually about 5-10 seconds afterward.
I believe at least this one is related to pasting into the game when a clipboard manager is running (CopyQ in this instance). The moment I paste (e.g. via ctrl-v) into the game, the Steam client crashes. Shutting down CopyQ before launching the game and pasting results in no Steam client crash.
Same crash here on Ubuntu 22.04, client build 1785799196 (installed via the deb steam-launcher package).
From the start of the update Steam enters a restart loop and always crashes before any UI is shown, with exactly:
steamuisharedjscontroller.cpp (549) : Failed creating offscreen shared JS context
Thread 1 "steam" received signal SIGTRAP (in steamui.so)
Additional data points that might help:
STEAM_DISABLE_GPU_HARDWARE_ACCELERATION=1, with -bigpicture, and on the publicbeta branch — still crashes the same way.steamwebhelper runs fine when launched manually; it only dies when spawned by the Steam client.console-linux.txt log also shows *** stack smashing detected *** during the loop.steam-runtime-steamrt/run missing, pv-run.sh error). I repaired the install by re-extracting /usr/lib/steam/bootstraplinux_ubuntu12_32.tar.xz and verified every binary CRC against steam_client_ubuntu12.installed — fully pristine, and the offscreen JS context crash still persists, so I don't think it is local corruption.Build 1785799196, Ubuntu 22.04, X11, swift 1789612669 in the loop. Happy to attach logs if needed.
FWIW ever since I've ran Steam without any clipboard manager running, I haven't had any crashing problems since -- whether I'm pasting or not, as crazy as it sounds.
CopyQ does seem to trigger it more often than qlipper did though. Either way, Steam should probably be more resilient to whatever interaction is going on as the crash was originating from steamui.so. It would be nice if I didn't have to shut down my clipboard manager for Steam, but at least there's a workaround for now...
Your system information
steamdistro package -- which just installs the installer and runs it from my understanding)Please describe your issue in as much detail as possible:
Ever since the end of July, the Steam client has been unreliable. Initially nothing had changed on my system (not even OS package updates) in a very long time, so I suspect it was some silent Steam client update that got pulled in.
In an effort to try to remedy the issue, I performed all OS updates, upgraded the nvidia (proprietary) driver to 595.x.x as that is the current latest production branch as of this writing. I tried rebooting. I tried temporarily disabling various things from the command line, such as the CEF sandbox and a few other things. I tried disabling GPU acceleration during one of the times the Steam client managed to start successfully. None of these things ultimately made a difference.
The Steam client behavior boils down to one of these scenarios:
Usually if it's working, it may work many times consecutively. Other times it may not start up many times consecutively.
This has been very frustrating to say the least. Up until this point I've had very good luck with the Steam client on Linux and hardly ever had it segfault or otherwise crash unexpectedly on me.
I found that when I could get the crash to happen with
DEBUGGER=gdb steam, it was pointing the steamui.so library, unlike a similar crashing report that was reported around the same time I started having problems:Additionally, I've been having similar issues where after launching some games when Steam does load, the client silently (and regularly) crashes with the backtrace pointing to libSDL3.so every time. It doesn't happen immediately after the game launches, usually about 5-10 seconds afterward.
Steps for reproducing this issue:
steamfrom the command line or from the application menu