Steam (steamwebhelper) crashing on start after recent update

[inferrna]

OS: Clear Linux System configuration was unchanged since the last successful run of steam.

Normal start

assert_20240304113150_38.dmp[30828]: Finished uploading minidump (out-of-process): success = yes
assert_20240304113150_38.dmp[30828]: response: CrashID=bp-730b3ddf-7535-41cd-b51d-cede92240303
assert_20240304113150_38.dmp[30828]: file ''/tmp/dumps/assert_20240304113150_38.dmp'', upload yes: ''CrashID=bp-730b3ddf-7535-41cd-b51d-cede92240303''

GPU acceleration disabled

assert_20240304113542_37.dmp[36770]: Finished uploading minidump (out-of-process): success = yes
assert_20240304113542_37.dmp[36770]: response: CrashID=bp-d8aa2486-b05d-462d-95f7-d47aa2240303
assert_20240304113542_37.dmp[36770]: file ''/tmp/dumps/assert_20240304113542_37.dmp'', upload yes: ''CrashID=bp-d8aa2486-b05d-462d-95f7-d47aa2240303''

Sandboxing disabled

assert_20240304113820_37.dmp[40681]: Finished uploading minidump (out-of-process): success = yes
assert_20240304113820_37.dmp[40681]: response: CrashID=bp-5c4b5bc2-ebf9-4732-9a28-216432240303
assert_20240304113820_37.dmp[40681]: file ''/tmp/dumps/assert_20240304113820_37.dmp'', upload yes: ''CrashID=bp-5c4b5bc2-ebf9-4732-9a28-216432240303''

Logs steam_logs2.zip

also reported in #10549

[smcv]

pressure-vessel-wrap[40134]: W: Using libGLX_mesa.so.0 from provider system for some but not all architectures! Will take /usr/share/drirc.d from provider.

As I think I mentioned elsewhere, this is only a warning and not a fatal error, but it would be good to look into this in your OS.

As documented in https://github.com/ValveSoftware/steam-for-linux/blob/master/README.md, Steam requires 64-bit (x86_64, amd64) and 32-bit (i386, IA32) graphics drivers, so I would normally expect you to have libGLX_mesa.so.0 for both 64- and 32-bit.

Since you mention Clear Linux: if I remember their filesystem layout correctly, I think that means both /usr/lib64/libGLX_mesa.so.0 and /usr/lib32/libGLX_mesa.so.0 ought to be present.

[smcv]

setlocale "en_US.UTF-8": No such file or directory
pressure-vessel-locale-gen: Missing locale en_US.UTF-8 (found in $LANG)
pressure-vessel-locale-gen: Generating locale en_US.UTF-8...
pressure-vessel-locale-gen: Generated locale en_US.UTF-8 successfully
pressure-vessel-adverb[40275]: W: Container startup will be faster if missing locales are created at OS level

As I mentioned elsewhere, this is only a warning and not a fatal error, but you can improve startup performance by arranging for the en_US.UTF-8 locale to exist. I don't know how locales normally work on Clear Linux.

To give you an idea of what this might involve: on Debian, which I'm more familiar with, you would either install the locales-all package, or uncomment en_US.UTF-8 in /etc/locale.gen and then run sudo locale-gen.

[smcv]

Unfortunately I don't see any obvious root causes for this crash in the logs.

One thing to try is to check whether ~/.config or ~/.config/cef_user_data are symbolic links. If they are, then that's #10547, which is hopefully going to be fixed in a future Steam release. You can work around this by using bind-mounts instead of symbolic links to offload data from one disk to another.

Another thing to try is to check whether /tmp/dumps is owned by a user ID other than your own. If it is, then that's probably the same thing as the original reporter of #10549. I know I asked you to separate this issue report from #10549, but that's because at the time it wasn't clear what the root cause for it was - we're now reasonably sure that /tmp/dumps having a different owner is causing that issue, but we're waiting to hear back from its reporter with confirmation.

If it isn't either of those, then I've reached the limits of what I can to do debug this, so someone with access to Steam internals will have to take over from here.

[smcv]

Another thing to try is to check whether /tmp/dumps is owned by a user ID other than your own

Actually, perhaps we can already rule out that theory, because you quoted Steam successfully uploading crash reports, and I don't think it would have been able to do that if /tmp/dumps was owned by someone else.

[inferrna]

Just added 32-bit GLX libs, still craches. (which was tricky because -Dglvnd=true disables libGL.so in 32-bit build)

assert_20240306021029_38.dmp[1676602]: Finished uploading minidump (out-of-process): success = yes
assert_20240306021029_38.dmp[1676602]: response: CrashID=bp-ad9c3e65-c619-4433-bd0e-3b6332240305
assert_20240306021029_38.dmp[1676602]: file ''/tmp/dumps/assert_20240306021029_38.dmp'', upload yes: ''CrashID=bp-ad9c3e65-c619-4433-bd0e-3b6332240305''

ls -ald ~/.config ~/.config/cef_user_data
drwx------ 1 inferno inferno 3060 Mar  6 10:09 /home/inferno/.config
drwx------ 1 inferno inferno   46 Jun 24  2022 /home/inferno/.config/cef_user_data

steam_logs3.zip

[K1ngfish3r]

Clear Linux here too. I am able to run steam through the .desktop file, but I crash when I try to run steam through the terminal steam-logs.tar.gz using tar -zcvf ~/Desktop/steam-logs.tar.gz ~/.steam/steam/logs log from the terminal I am unable to obtain a log from the SLR at /home/i/.local/share/Steam/steamapps/common/SteamLinuxRuntime_sniper/var even after using STEAM_LINUX_RUNTIME_VERBOSE=1 STEAM_LINUX_RUNTIME_LOG=1 steam

i@clr~ $ ls -ald ~/.config ~/.config/cef_user_data
drwx------ 33 i i 4096 Mar 10 00:48 /home/i/.config
drwx------  4 i i 4096 Feb 27 12:51 /home/i/.config/cef_user_data

.desktop file is obtained from http://repo.steampowered.com/steam/archive/precise/steam_latest.tar.gz > sudo make install

UPDATE: with debugger=gdb log this doesn't look very helpful though

[tfogal]

Hi, I'm hitting the same crash on startup after an update, too. I believe it to be an EGL issue; more information inline.

For Valve employees, ticket HT-DHFG-GGBD-85VD has steamwebhelper.log attached, which may help.

I see the same symptoms as inferrna, but have more logs:

steam.sh[37879]: Restarting Steam by request...
Unable to determine whether the expected Nvidia drivers are available.
The Steam client may have limited functionality.
steam.sh[37879]: Running Steam on ubuntu 22.04 64-bit
steam.sh[37879]: STEAM_RUNTIME has been set by the user to: /home/xxxxxx/.steam/ubuntu12_32/steam-runtime
setup.sh[39287]: Steam runtime environment up-to-date!
steam.sh[37879]: Steam client's requirements are satisfied
tid(39357) burning pthread_key_t == 0 so we never use it
[2024-03-09 09:20:23] Startup - updater built Mar 6 2024 20:27:25
[2024-03-09 09:20:23] Startup - Steam Client launched with: '/home/xxxxxx/.steam/ubuntu12_32/steam'
minidumps folder is set to /tmp/dumps
03/09 09:20:23 Init: Installing breakpad exception handler for appid(steam)/version(1709846872)/tid(39357)
[2024-03-09 09:20:23] Loading cached metrics from disk (/home/xxxxxx/.steam/package/steam_client_metrics.bin)
[2024-03-09 09:20:23] Using the following download hosts for Public, Realm steamglobal
[2024-03-09 09:20:23] 1. [https://client-update.akamai.steamstatic.com,](steam://openurl/https://client-update.akamai.steamstatic.com,) /, Realm 'steamglobal', weight was 1000, source = 'update_hosts_cached.vdf'
[2024-03-09 09:20:23] 2. [https://cdn.cloudflare.steamstatic.com,](steam://openurl/https://cdn.cloudflare.steamstatic.com,) /client/, Realm 'steamglobal', weight was 1, source = 'update_hosts_cached.vdf'
[2024-03-09 09:20:23] 3. [https://cdn.steamstatic.com,](steam://openurl/https://cdn.steamstatic.com,) /client/, Realm 'steamglobal', weight was 1, source = 'baked in'
[2024-03-09 09:20:23] Verifying installation...
[2024-03-09 09:20:23] Verification complete
UpdateUI: skip show logo
Steam logging initialized: directory: /home/xxxxxx/.steam/logs

XRRGetOutputInfo Workaround: initialized with override: 0 real: 0xf0d349c0
XRRGetCrtcInfo Workaround: initialized with override: 0 real: 0xf0d331f0
steamwebhelper.sh[39390]: === Sat Mar 9 09:20:49 AM PST 2024 ===
steamwebhelper.sh[39390]: Starting steamwebhelper under bootstrap sniper steam runtime at /home/tfogal/.steam/ubuntu12_64/steam-runtime-sniper
CAppInfoCacheReadFromDiskThread took 147 milliseconds to initialize
Steam Runtime Launch Service: starting steam-runtime-launcher-service
Steam Runtime Launch Service: steam-runtime-launcher-service is running pid 39465
bus_name=com.steampowered.PressureVessel.LaunchAlongsideSteam
src/steamUI/steamuisharedjscontroller.cpp (546) : Failed creating offscreen shared JS context
src/steamUI/steamuisharedjscontroller.cpp (546) : Failed creating offscreen shared JS context
03/09 09:21:16 Init: Installing breakpad exception handler for appid(steam)/version(1709846872)/tid(39357)
assert_20240309092116_27.dmp[39591]: Uploading dump (out-of-process)
/tmp/dumps/assert_20240309092116_27.dmp
assert_20240309092116_27.dmp[39591]: Finished uploading minidump (out-of-process): success = yes
assert_20240309092116_27.dmp[39591]: response: CrashID=bp-8571ed00-3286-4325-bd83-32d7a2240309
assert_20240309092116_27.dmp[39591]: file ''/tmp/dumps/assert_20240309092116_27.dmp'', upload yes: ''CrashID=bp-8571ed00-3286-4325-bd83-32d7a2240309''
steamwebhelper.sh[39622]: === Sat Mar 9 09:21:17 AM PST 2024 ===
steamwebhelper.sh[39622]: Starting steamwebhelper under bootstrap sniper steam runtime at /home/tfogal/.steam/ubuntu12_64/steam-runtime-sniper
[2024-03-09 09:22:50] Background update loop checking for update. . .
[2024-03-09 09:22:50] Checking for available updates...
[2024-03-09 09:22:50] Downloading manifest: [https://client-update.akamai.steamstatic.com/steam_client_ubuntu12?t=1674554388](steam://openurl/https://client-update.akamai.steamstatic.com/steam_client_ubuntu12?t=1674554388)
[2024-03-09 09:22:50] Manifest download: send request
[2024-03-09 09:22:50] Manifest download: waiting for download to finish
[2024-03-09 09:22:50] Manifest download: finished
[2024-03-09 09:22:50] Download skipped: /steam_client_ubuntu12?t=1674554388 version 1709846872, installed version 1709846872, existing pending version 0
[2024-03-09 09:22:50] Nothing to do

Reading through that terminal output, I saw a log for steamwebhelper and it appeared to have an issue initializing EGL. The log for it is in ticket HT-DHFG-GGBD-85VD; apologies that I no longer have it to attach here.

glx is fine:

$ glxinfo | grep -i OpenGL
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: NVIDIA GeForce GTX TITAN X/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 535.154.05
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6.0 NVIDIA 535.154.05
OpenGL shading language version string: 4.60 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 535.154.05
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:

and glxgears starts up / runs fine. But of course glx is not EGL. The output of eglinfo > eglinfo.txt is attached; from a quick glance EGL seems fine as well.

eglinfo.txt

There's a chance this might be a race. Yesterday I managed to get steam to startup by manually running "Lumencraft" from the command line; it seemed to need steam APIs and start the steam client itself, and magically worked. The same trick did not work today, and so I now believe I just got lucky with that startup. Corroborating that theory: today I occasionally ran steam in my terminal while I was doing something else. It took approximately an hour, but eventually I got the steam login window instead of a notification that steamwebhelper crashed. Once the login window comes up, all is well / the client behaves perfectly.

FWIW, I now have "Enable GPU accelerated rendering in web views" disabled in my settings (turned it off yesterday, after the issues started). The issues continued today so it seems this setting did not have impact.

I wonder if steam is sandboxing steamwebhelper but also trying to use EGL, and that sandboxing is preventing access to GL? Just speculation. If it's fruitful, is there a way to tell steamwebhelper to not bother with GPU acceleration? There's an option on this for the main client, but it's not clear that it impacts steamwebhelper.

My system:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.4 LTS
Release: 22.04
Codename: jammy

[tfogal]

Reading through @K1ngfish3r 's gdb gist (thanks for including that!), I see a note about a javascript offscreen context failing to be created, in an implementation file that suggests it is managing a controller. Note in the log I paste above, I see the same error. I also tried manually running a game from the command line while steam was not running, and the last thing the game printed before crashing was something related to initializing a controller.

So another hypothesis: in a recent update, something changed in the webhelper (maybe just an update of a dependency) such that it now pulls in ANGLE and tries to do GPU rendering. But something is (very sanely) blocking a joystick from accessing the GPU.

@K1ngfish3r since it's broken for you from the command line and works from a .desktop file, I wonder if there a difference in environment variables? Is there a way to create a .desktop file that just runs env and stores the contents to a file? Then you could diff the env you get from exec'ing the .desktop and the env you get from the terminal to see if there's something unique about the .desktop environment.

That wouldn't explain my situation, but it might help us debug.

[ipr]

Same problem exists on Debian as well. I tested downgrading Mesa to 23.3 from 24.0 to see if there's a difference, no help. Also tried turning off hardware acceleration.

This appears always on first start of the Steam. Once you are in Steam client, exit and start it again to fix the situation but that is slow and cumbersome.

But since it seems to vary on start timing there is perhaps something in initialization not being fully ready when the "friends" app is starting? (It is always that one that does not work when client has loaded in addition to profile being not loaded correctly.)

[ipr]

Some clarification: in the first start (when crashing) I don't see the "login splash screen" at all. In the second start (after exiting once) the login splash is visible almost immediately and there's no crash. If login didn't work this might explain why profile and friends app are not working either?

[ipr]

Problem reappears after rebooting computer when starting the client takes longest. Logging out and back in does not cause the crash. So it all works when things are cached and fast to access, crashes when reading from disk..

[ipr]

Since it always takes a long to appear, it might be a timeout instead of simple crash? Steamwebhelper has no chance of starting at all when the client is busy eating the harddrive?

[JORGETECH]

I think I'm also running into a similar issue in (K)Ubuntu 22.04 LTS using the "amdgpu" display driver, I started having this issue after a recent update.

But for me it's really inconsistent, I observed it has more tendency to crash in the first launch, if I close Steam using the crash dialog that appears and open again I can eventually get Steam working, sometimes I need to do this process three or four times until steamwebhelper stops crashing. I will try to get logs as soon as I can.

I should also mention I am running the entire Steam installation from an spinning hard drive using a symlink to the ".steam" folder inside my home folder that lives in an SSD, I wonder if there is a race condition caused by Steam taking too long to start.

EDIT: I forgot to mention I am using the Steam Families Beta but I started having this issue before using it.

[DocMAX]

My home dir /home/user is a symlink, is it the same problem like have a symlink on .config?

[ipr]

My home dir /home/user is a symlink, is it the same problem like have a symlink on .config?

It might be different problem.

I don't see symlink on my system and if it were about symlink it would fail consistently instead of only some times during starting.

[K1ngfish3r]

Updated log with debugger=gdb Run with steam client beta and opted into SLR 3.0 (sniper) client_beta

the .desktop file still works but running steam through the terminal fails. I am not sure how to diff any env differences between the .desktop file and the steam command run directly from the terminal. I would like some help on this matter

[smcv]

Run with steam client beta

This is potentially relevant. Did it work when you were using the stable version?

You can switch between beta and stable from the command-line if Steam is too broken to do that from the GUI. Completely exit from Steam, then to switch from beta to stable:

rm ~/.steam/root/package/beta

or from stable to public beta:

printf publicbeta > ~/.steam/root/package/beta

and opted into SLR 3.0 (sniper) client_beta

If Steam is crashing during startup, then that's happening too early for this to matter. The copy of SLR 3.0 (sniper) in steamapps/common is only used to run games, not to run Steam itself.

There is a different version of SLR 3.0 (sniper) that is used to run parts of Steam itself, in ~/.steam/root/ubuntu12_64. It automatically unpacks into ~/.steam/root/ubuntu12_64/steam-runtime-sniper/ during Steam startup if necessary.

I am unable to obtain a log from the SLR at /home/i/.local/share/Steam/steamapps/common/SteamLinuxRuntime_sniper/var even after using STEAM_LINUX_RUNTIME_VERBOSE=1 STEAM_LINUX_RUNTIME_LOG=1 steam

That's because that copy is only used to run games.

The easiest way to get a detailed log from the copy that is used to run steamwebhelper is to run as STEAM_LINUX_RUNTIME_VERBOSE=1 steam, but not use STEAM_LINUX_RUNTIME_LOG=1. You'll find the log in ~/.steam/steam/logs/steamwebhelper.log.

[K1ngfish3r]

Running steam in the terminal with either stable/beta causes steamwebhelper crash message to appear Running the .desktop file with either stable/beta works normally and I'm able to use Steam.

Find attached steamwebhelper.log run with Stable and with Beta

Additionally, find attached steamwebhelper.log run with .desktop file I added STEAM_LINUX_RUNTIME_VERBOSE=1 to the Exec field like so Exec=STEAM_LINUX_RUNTIME_VERBOSE=1 /usr/bin/steam %U and the output is slightly longer than without. The above is run on steam client beta

EDIT: I'm able to echo $LANG => en_US.UTF-8 but I still seem to be getting those locale not found messages.

[smcv]

@K1ngfish3r:

Running steam in the terminal with either stable/beta causes steamwebhelper crash message to appear

OK, thanks, so this affects stable/beta equally and is not a new regression in the current beta cycle. That's always useful information to know.

Additionally, find attached steamwebhelper.log run with .desktop file I added STEAM_LINUX_RUNTIME_VERBOSE=1 to the Exec field like so Exec=STEAM_LINUX_RUNTIME_VERBOSE=1 /usr/bin/steam %U and the output is slightly longer than without. The above is run on steam client beta

Are you sure the log you attached is with that change, and are you sure that your desktop environment had reloaded the modified .desktop file? The log you attached does not include verbose output from SLR. I would have expected to see hundreds of lines of extra output marked as coming from pressure-vessel-wrap.

I would have expected that Exec=STEAM_LINUX_RUNTIME_VERBOSE=1 /usr/bin/steam %U would not work at all (not a Steam bug), and instead you would have to use Exec=env STEAM_LINUX_RUNTIME_VERBOSE=1 /usr/bin/steam %U (the difference: adding the env prefix).

EDIT: I'm able to echo $LANG => en_US.UTF-8 but I still seem to be getting those locale not found messages.

This is a side issue that is slowing things down but should not completely break Steam, so we should discuss it somewhere else.

[smcv]

Both of @K1ngfish3r's logs end with:

pressure-vessel-wrap[14823]: D: Replacing self with srt-bwrap...
bwrap: Can't make symlink at /var/cache/ldconfig/ld.so.cache: File exists

This is probably not the same issue that was originally seen by @inferrna (because if it was, then @inferrna would have reported the same error message, but would not have reported any messages coming from steamwebhelper), so we should convert it into its own issue report.

[K1ngfish3r]

The log went from 10 lines to 20 lines so I thought that was the extent of the change. my bad.

@smcv Find attached steamwebhelper.log with the updated command Exec=env STEAM_LINUX_RUNTIME_VERBOSE=1 /usr/bin/steam %U

Surprisingly, steam ran fine even though I botched the first time.

[smcv]

@K1ngfish3r, I've opened #10789 to represent your issue where steamwebhelper.log ends with bwrap: Can't make symlink at /var/cache/ldconfig/ld.so.cache: File exists. We should take any further discussion of your issue there.

Other users who see that message can follow up on #10789 too. This probably only affects users of Clear Linux.

[smcv]

If you do not see that message, even if the symptom is the same, please do not reply to #10789.

The steamwebhelper failing to start is a generic symptom which can happen for many unrelated reasons. Please do not assume that, just because you see the same symptom, it has the same root cause. To diagnose what is actually happening, Steam developers will need to see the logs in ~/.steam/steam/logs/, especially steamwebhelper.log.

[smcv]

@tfogal, there is not enough information here to tell whether you are encountering the same issue that was originally reported here by inferrna, or whether you are seeing the same symptom for a different reason. Please collect a new steamwebhelper.log and check for distinctive error messages.

If in doubt, please open a separate issue, with the title as distinctive as possible: closing an issue as a duplicate is much faster and easier than disentangling an issue report that contains multiple root causes.

I saw a log for steamwebhelper and it appeared to have an issue initializing EGL

Sorry, if we are going to make progress on this, we will need to see the actual logs, not just your interpretation of them; and the information about your system that is requested by the issue report template is also important.

Note that some error messages involving ANGLE and EGL often appear in steamwebhelper.log, even on systems where steamwebhelper is working correctly. For example, this seems to be normal on my Ubuntu 22.04/Nvidia test system:

These warnings look scary, but seem to be harmless

``` [0417/201955.530870:INFO:crash_reporting.cc(239)] Crash reporting enabled for process: browser [0417/201955.532001:WARNING:task_impl.cc(32)] No task runner for threadId 0 [0417/201955.533011:WARNING:task_impl.cc(32)] No task runner for threadId 0 [0417/201955.556870:WARNING:crash_reporting.cc(278)] Failed to set crash key: UserID with value: 0 [0417/201955.556947:WARNING:crash_reporting.cc(278)] Failed to set crash key: BuildID with value: 1712795774 [0417/201955.556952:WARNING:crash_reporting.cc(278)] Failed to set crash key: SteamUniverse with value: Public [0417/201955.556956:WARNING:crash_reporting.cc(278)] Failed to set crash key: Vendor with value: Valve [0417/201955.556961:WARNING:crash_reporting.cc(278)] Failed to set crash key: Platform with value: Linux [0417/201955.556991:WARNING:crash_reporting.cc(278)] Failed to set crash key: UserID with value: 0 [0417/201955.557053:WARNING:crash_reporting.cc(278)] Failed to set crash key: BuildID with value: 1712795774 [0417/201955.557058:WARNING:crash_reporting.cc(278)] Failed to set crash key: SteamUniverse with value: Public [0417/201955.557062:WARNING:crash_reporting.cc(278)] Failed to set crash key: Vendor with value: Valve [0417/201955.557066:WARNING:crash_reporting.cc(278)] Failed to set crash key: Platform with value: Linux Gtk-Message: 20:19:55.627: Failed to load module "canberra-gtk-module" Gtk-Message: 20:19:55.628: Failed to load module "canberra-gtk-module" [0417/201955.645788:INFO:crash_reporting.cc(262)] Crash reporting enabled for process: gpu-process [0417/201955.874114:ERROR:angle_platform_impl.cc(43)] Display.cpp:1021 (initialize): ANGLE Display::initialize error 0: Internal Vulkan error (-3): Initialization of an object could not be completed for implementation-specific reasons, in ../../third_party/angle/src/libANGLE/renderer/vulkan/RendererVk.cpp, initialize:1470. ERR: Display.cpp:1021 (initialize): ANGLE Display::initialize error 0: Internal Vulkan error (-3): Initialization of an object could not be completed for implementation-specific reasons, in ../../third_party/angle/src/libANGLE/renderer/vulkan/RendererVk.cpp, initialize:1470. [0417/201955.877674:ERROR:gl_display.cc(508)] EGL Driver message (Critical) eglInitialize: Internal Vulkan error (-3): Initialization of an object could not be completed for implementation-specific reasons, in ../../third_party/angle/src/libANGLE/renderer/vulkan/RendererVk.cpp, initialize:1470. [0417/201955.877896:ERROR:gl_display.cc(932)] eglInitialize SwANGLE failed with error EGL_NOT_INITIALIZED [0417/201955.878081:ERROR:gl_ozone_egl.cc(23)] GLDisplayEGL::Initialize failed. [0417/201955.881187:ERROR:viz_main_impl.cc(186)] Exiting GPU process due to errors during initialization [0417/201955.893571:INFO:crash_reporting.cc(262)] Crash reporting enabled for process: gpu-process [0417/201955.897444:ERROR:gpu_init.cc(523)] Passthrough is not supported, GL is disabled, ANGLE is [0417/201955.915371:WARNING:crash_reporting.cc(278)] Failed to set crash key: UserID with value: 0 [0417/201955.915450:WARNING:crash_reporting.cc(278)] Failed to set crash key: BuildID with value: 1712795774 [0417/201955.915455:WARNING:crash_reporting.cc(278)] Failed to set crash key: SteamUniverse with value: Public [0417/201955.915459:WARNING:crash_reporting.cc(278)] Failed to set crash key: Vendor with value: Valve [0417/201955.915463:WARNING:crash_reporting.cc(278)] Failed to set crash key: Platform with value: Linux [0417/201955.916199:INFO:crash_reporting.cc(239)] Crash reporting enabled for process: utility [0417/201955.951945:INFO:crash_reporting.cc(262)] Crash reporting enabled for process: utility [0417/201956.485456:INFO:crash_reporting.cc(262)] Crash reporting enabled for process: renderer [0417/201956.489390:INFO:crash_reporting.cc(262)] Crash reporting enabled for process: renderer (steamwebhelper:15204): dbind-WARNING **: 20:19:58.621: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/1000/at-spi/bus_1: No such file or directory ```

so you cannot necessarily assume that a particular error message is fatal.

[smcv]

@ipr, there is not enough information here to know what is happening on your specific system, and you have not provided logs or system details beyond "it's Debian".

it all works when things are cached and fast to access, crashes when reading from disk

This sounds similar to #10581. Is your disk or filesystem known to be particularly slow?

(My test machines used for Steam Linux Runtime development have a traditional magnetic HDD, not a SSD, and I have not encountered this problem myself.)

[smcv]

@JORGETECH, there is not enough information here to know what is happening on your specific system, and you have not provided logs. If your disk or filesystem is known to be particularly slow, then it might be the same thing as #10581.

[smcv]

@DocMAX:

My home dir /home/user is a symlink, is it the same problem like have a symlink on .config?

You have not provided any logs or details of your system beyond what I quoted here, so I cannot say what is happening on your particular system.

As a general principle to get better robustness, whenever you are offloading things to a different disk, I would recommend using bind-mounts in preference to symlinks.

Having said that, the known issue for ~/.config being a symlink was resolved: #10547, #10552.

[smcv]

@kisak-valve, we can probably improve the signal-to-noise ratio here by marking most of @K1ngfish3r's comments as hidden (and at your discretion, perhaps some of my replies to them as well), and taking discussion of the "Can't make symlink at /var/cache/ldconfig/ld.so.cache: File exists" issue to #10789.

Unfortunately we still don't know what's going wrong for the original reporter of this issue, but @K1ngfish3r was able to quote a distinctive fatal error message that did not appear in the original reporter's logs, so we can be confident that the bug encountered by @K1ngfish3r is something different (and it will probably also be easier to fix).

[ipr]

With the new beta version steamwebhelper is still crashing on Debian. Yet this is somehow worse that main UI does not start at all when steamwebhelper crashes.

Steam beta 1713317598 Client build date 17.4., Web build date 15.4.

Kernel 6.8.7, Mesa 23.3.5

Logs from stable version: steamwebhelper.log

[ipr]

One line that does not appear upon successfully starting:

[0417/224920.216117:INFO:CONSOLE(1)] "Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'RegisterForComputerActiveStateChange')", source: https://steamloopback.host/libraries/libraries~2dcc5aaf7.js?contenthash=3d64e3d015aef081e98d (1)

This seems to be only in log when crashing.

[tfogal]

I am not sure how to diff any env differences between the .desktop file and the steam command run directly from the terminal. I would like some help on this matter

Hi @K1ngfish3r, to run from the terminal end get your environment, run:

$ env &> broken.txt

This will create a file broken.txt with your environment variables from the terminal.

To get the environment from the .desktop file, I'd ask you to copy your .desktop file to a new one, and then edit the command inside the new one (probably by right-clicking and going into a 'properties' or similar). The command is probably something like steam right now, but change it to something like env > ${HOME}/working.txt. When you double click the modified desktop file, it'll probably look like nothing is happening. But check your home directory for a working.txt after the fact; it should be there.

Once you have the two files of your environments, you could run:

$ diff -u broken.txt working.txt

and it will show some lines with - and + in front; that diff output should be elucidating.

[tfogal]

In fact, I have to thank @K1ngfish3r because it got me thinking about environments. I have determined that, on my system:

env -i HOME="${HOME}" DISPLAY="${DISPLAY}" XAUTHORITY="${XAUTHORITY}" steam

works, while:

env -i HOME="${HOME}" DISPLAY="${DISPLAY}" XDG_RUNTIME_DIR="${XDG_RUNTIME_DIR}" XAUTHORITY="${XAUTHORITY}" steam

fails. When it works, steam starts up in 36--50 seconds (high variance). When it fails, steam takes 1m1s to run.

Attaching logs from these two cases, but they're really not elucidating.

broken.tar.gz working.tar.gz

Interestingly, XDG_RUNTIME_DIRis what's required to get audio out of my system (verified by using mplayer on a video with similar env -i command lines above).

Hypothesizing: something is trying to initialize audio, but it's taking much longer than expected and a timeout occurs, causing cascading failures. I do not know why the initialization is taking so long. Note that mplayer's startup time appears identical whether it's got the XDG_RUNTIME_DIR variable or not.

[smcv]

@tfogal, please open a separate issue with a title like steamwebhelper not starting when XDG_RUNTIME_DIR is set, with full details of your system: that seems like something specific enough to be investigated separately.

Hypothesizing: something is trying to initialize audio

It could be audio, or it could be anything else that uses XDG_RUNTIME_DIR (Wayland, Pipewire video capture, D-Bus, many other possibilities).

[smcv]

@ipr:

One line that does not appear upon successfully starting:

[0417/224920.216117:INFO:CONSOLE(1)] "Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'RegisterForComputerActiveStateChange')", source: https://steamloopback.host/libraries/libraries~2dcc5aaf7.js?contenthash=3d64e3d015aef081e98d (1)

This seems to be only in log when crashing.

This seems notable enough to be something that would be useful for a steamwebhelper developer to investigate as a distinct issue. Please open a separate issue with full details and logs, and mention "TypeError: Cannot read properties of undefined (reading 'RegisterForComputerActiveStateChange')" in the title.

[inferrna]

Steam updated to 1714854927 still same error

assert_20240512135300_30.dmp[261153]: Finished uploading minidump (out-of-process): success = yes
assert_20240512135300_30.dmp[261153]: response: CrashID=bp-feaf08cd-14b7-45f5-80f8-1e6572240512
assert_20240512135300_30.dmp[261153]: file ''/tmp/dumps/assert_20240512135300_30.dmp'', upload yes: ''CrashID=bp-feaf08cd-14b7-45f5-80f8-1e6572240512''

[mardab]

I got caught in infinite loop during unpacking stage in version 1715635533.

After manually removing all steam-runtime-sniper items, including force-removing non-.new folder, which had a permission issue, just a normal start of steam was enough for me to correct that problem.

Take this info with a big pinch of salt, but if it helps anyone I'd rather post it.

[smcv]

I got caught in infinite loop during unpacking stage in version 1715635533.

This is probably a separate issue. There are several things that can cause steam-runtime-sniper to not start correctly, and they all have similar superficial symptoms. In the original report here from @inferrna, the container runtime was starting correctly, but then steamwebhelper was crashing. We don't fully understand what is happening there (and probably only steamwebhelper developers can) but it is not the same as a problem with the unpacking stage.

If you are not @inferrna and you do not have evidence that you're seeing exactly the same crash that @inferrna sees, please open separate issues instead of replying to this one.

including force-removing non-.new folder, which had a permission issue

A permissions issue is a new thing to have seen there. Please send as much information as you can remember or obtain from logs to a separate issue report, mentioning in the title that it's a permissions issue while unpacking steam-runtime-sniper.

(We cannot fix issues from a description as broad as "permission issue", but if you can provide more information then we might be able to figure out what was going on.)

[inferrna]

Fixed for me with 1718305227

[smcv]

@inferrna wrote:

Fixed for me with 1718305227

1718305227 is the current beta version of the Steam client (build date 2024-06-13).

Since @inferrna is the original reporter of this issue, we should probably close it now, to avoid attracting replies from other users who are getting a similar symptom for a different reason (cc @kisak-valve).

For anyone else who is getting similar symptoms, you could try upgrading to the beta branch. If Steam is not starting at all, you will not be able to switch to the beta through the UI, but you can still upgrade to the beta like this:

1. Completely exit from Steam
2. echo publicbeta > ~/.steam/root/package/beta
3. Start Steam again

(Similarly, if the beta is not working, you can go back to the stable branch by deleting ~/.steam/root/package/beta and restarting Steam.)

If upgrading to the beta resolves this for you, then maybe you were experiencing the same issue as @inferrna. If so, there is no need to reply here. The same fix should make its way into the stable branch of Steam at some point in the future.

For anyone who is still getting similar symptoms after upgrading to beta 1718305227 or later, please open a separate issue instead of replying to this one, with as much information as you can provide (for example any distinctive error messages). A crash similar to the one reported here can happen for several reasons, but each reason needs to be fixed separately: there is no magic bullet that will fix every possible reason for a steamwebhelper crash.

[smcv]

1718305227 is the current beta version of the Steam client (build date 2024-06-13)

This is now also the stable version of the Steam client, so anyone who was experiencing this issue for the same reasons as @inferrna should now find that the stable version also works.

Again, if you are still getting similar symptoms after upgrading to 1718305227 or later, please open a separate issue.