@smcv iirc the problem here is libsoup needed to make a bug fix for certain sites which required new symbol in libnghttp2. There is probably obsolete version of latter loaded combined with libsoup built against newer one.

Does the bad libnghttp2 originate from Steam Runtime?

I'm writing up why this happens, please wait.

I believe the root cause of this issue is that the steamwebhelper in ~/.steam/root/ubuntu12_64 bundles a copy of libnghttp2.so.14, which is (or was previously?) used by some component of Steam. The likely cause of the crash is this:

• steamwebhelper depends on lots of libraries. (We don't yet know exactly which libraries are involved here.)
• For each dependency library, the Steam Runtime mechanism in ~/.steam/root/ubuntu12_64/steam-runtime-heavy automatically selects whether to use the host system's copy, or the copy in ~/.steam/root/ubuntu12_64/steam-runtime-heavy. What should happen here is, for each dependency library:
  • if it is not included in steam-runtime-heavy (libc.so.6, libGL.so.1, others): we use the copy from the host system
  • if it is not installed in the host system: we use the copy from steam-runtime-heavy
  • if it is installed in both places: we use whichever copy is newer, defaulting to the system copy if we're unable to decide
• To see the symptom reported here, there must be some library that:
  • is installed on the host system
  • depends on libsoup-3.0.so.0
  • is depended on, directly or indirectly, by steamwebhelper
• The system copy of libsoup-3.0.so.0 requires a relatively new version of libnghttp2.so.14, presumably for the reason @nanonyme mentioned (but the precise reason isn't important, all that's important is that it requires a relatively new version)
• The copy of libnghttp2.so.14 bundled with Steam is older, but is added to the LD_LIBRARY_PATH and is used unconditionally, in preference to the system copy
• => crash

If libnghttp2.so.14 was in the Steam Runtime, then we would not see this symptom: we would look at the system copy, look at the Steam Runtime copy, decide that the Steam Runtime copy is older, and use the system copy instead, solving the problem. But libnghttp2.so.14 is not in the Steam Runtime: it's directly bundled with steamwebhelper, bypassing the Steam Runtime mechanisms that are there to solve this sort of thing.

I don't have access to Steam's source code or build system, but from applying some grep to Steam beta 1681864962, it appears that all the components of Steam that use libnghttp functions:

• ubuntu12_32/panorama/panorama.so
• ubuntu12_32/steamservice.so
• ubuntu12_32/libvideo.so
• ubuntu12_32/steam
• ubuntu12_32/steamui.so
• ubuntu12_32/steamclient.so

have been converted to link libnghttp2 statically instead of dynamically.

If that's the case, then I think this crash can be resolved by Steam developers finishing that change, by removing ubuntu12_*/libnghttp2.so.* from the Steam download, and ensuring that they get deleted when Steam upgrades itself.

(Individual users can't easily do that as a workaround, because Steam validates its downloaded files on startup, so it will just put them back.)

To see the symptom reported here, there must be some library that:

• is installed on the host system
• depends on libsoup-3.0.so.0
• is depended on, directly or indirectly, by steamwebhelper

Another possible dependency chain causing similar issues would be:

steamwebhelper -> (something) -> libcurl*.so.* -> libnghttp2.so.14

@Mhlov (also using bookworm) says that apt install libnghttp2-14:i386 was a successful workaround for them. If this works, it is a less damaging workaround than using LD_PRELOAD.

Given that analysis, I'm surprised this works! I wonder whether @mhlov might have been seeing a different symptom, involving some 32-bit process crashing (not the 64-bit steamwebhelper, but some other part of Steam).

However, removing the bundled libnghttp2.so.14 from both ubuntu12_32/ and ubuntu12_64/ would solve this in a quite general way.

Note my point was that this symbol is very new. It's somewhere from this winter. We added it into runtime as part of bug fix due to gnome runtime requirements (details are irrelevant) probably faster than various distros but this same problem should become gradually prevalent.

apt install libnghttp2-14:i386 didn't work for me
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libnghttp2.so.14 steam worked
Ubuntu 23.04

From @OlegAckbar's log on #9357, it seems the component that is crashing is zenity. I still think the correct solution is removing the bundled libnghttp2.so.14, but it might also be possible to make the Steam Runtime scripts more resilient so that they continue even if zenity crashes.

All the identifiable reports of this have been on Debian 12 prereleases or on Ubuntu 23.04. I think the failure mode seen by @OlegAckbar (and maybe others) is more likely to happen on recent Debian and Ubuntu than on other distributions, because those distributions combine two factors:

• they're recent (so their libsoup requires a newer libnghttp2 than the one provided by Steam, unlike for example Debian 11);
• their zenity is compiled with WebKit support enabled, so it depends on libsoup

Other distributions like at least Fedora and (recent) Arch avoid this failure mode by having a version of zenity that was compiled with WebKit support disabled, which indirectly makes it not depend on libsoup, avoiding this. It's too late to remove that dependency during the Debian 12 release cycle, but it's possible that it might be removed in Debian 13.

it might also be possible to make the Steam Runtime scripts more resilient so that they continue even if zenity crashes

ValveSoftware/steam-runtime@3760856 implements this. The current Steam beta as of today (built 2023-05-03) does not have that change yet, but a future beta hopefully will.

That only fixes that zenity issue (which is admittedly more critical if it prevents updating) and not this original steamwebhelper problem, right?

That only fixes that zenity issue (which is admittedly more critical if it prevents updating) and not this original steamwebhelper problem, right?

This doesn't fix the fact that Steam has a libnghttp2.so.14 in its LD_LIBRARY_PATH, which is outside my control (I only help to maintain the Steam Runtime, not Steam itself).

What that means in terms of end-user-visible symptoms is unclear. My current theory is that the symptom reported by @creichen and @Mhlov:

• the login screen appears, but is blank
• there is an error message logged about nghttp2_option_set_no_rfc9113_leading_and_trailing_ws_validation being undefined

is not actually caused by the steamwebhelper binary crashing. Instead, I think it's caused by zenity failing to start, which caused setup.sh to fail (until I worked around it in ValveSoftware/steam-runtime@3760856), which caused steam-runtime-heavy.sh to fail, which caused steamwebhelper.sh to fail, meaning that the steamwebhelper binary never actually started.

If that theory is correct, then after a version containing ValveSoftware/steam-runtime@3760856 goes out to the public, @creichen, @Mhlov and anyone else in the same situation will find that they have this symptom after removing any workarounds that they might be using

• the zenity popup that is meant to have a progress bar and "Reconfiguring Steam runtime environment..." won't appear
• and a message about nghttp2_option_set_no_rfc9113_leading_and_trailing_ws_validation will still appear in steamwebhelper.log or in Steam's output
• but the UI will start up correctly and they will be able to interact with Steam

Or, if there is also a problem with steamwebhelper which causes that to fail to start, then the UI will still not start for the affected users (and we'll need to look at updated logs and try to work out what the next change needs to be). We won't find out which of these is true until a suitable beta goes out to the public.

I still think that the long term fix is for Steam to stop having a copy of libnghttp2.so.14 in its LD_LIBRARY_PATH, but I am not able to change that, and there have been enough regressions reported in recent betas that it is unlikely to be anyone's top priority for a while.

it might also be possible to make the Steam Runtime scripts more resilient so that they continue even if zenity crashes

ValveSoftware/steam-runtime@3760856 implements this.

That change went out in public betas in 1683253302 (2023-05-05) or earlier. I've confirmed (by adding an intentionally-failing zenity script to my PATH) that startup now works even if zenity is broken.

I still think that the long term fix is for Steam to stop having a copy of libnghttp2.so.14 in its LD_LIBRARY_PATH

That's unresolved.

Just wanted to add that I'm seeing this same issue on Gentoo (rolling releases) right now. It's prohibiting Steam to start, but the LD_PRELOAD helped with the issue.

My error message was

assert_20230617231533_30.dmp[180736]: file ''/tmp/dumps/assert_20230617231533_30.dmp'', upload no: ''/usr/lib/libcurl.so: undefined symbol: nghttp2_option_set_no_rfc9113_leading_and_trailing_ws_validation''

My error message was

assert_20230617231533_30.dmp[180736]: file ''/tmp/dumps/assert_20230617231533_30.dmp'', upload no: ''/usr/lib/libcurl.so: undefined symbol: nghttp2_option_set_no_rfc9113_leading_and_trailing_ws_validation''

I think that's a crash dump failing to upload, because the bundled copy of nghttp2 breaks the crash-dump uploader. The actual crash should have been somewhere earlier in Steam's output.

Eeeh, it sounds reasonably bad if Valve is missing unknown amount of crashdumps but possibly increasing because of this.

I still think that the long term fix is for Steam to stop having a copy of libnghttp2.so.14 in its LD_LIBRARY_PATH

Steam beta 1687306661 (2023-06-21) removed its copy of libnghttp2.so.14, so this should now be fixed. If you are affected by this issue, please remove any workarounds you are using (LD_PRELOAD or similar), then upgrade to the beta branch.

If Steam is starting successfully but you are seeing crashes with this message somewhere else, you can switch to the beta in Settings -> Interface -> Client Beta Participation -> choose "Steam Beta Update".

If Steam is not starting successfully, obviously you will not be able to access the Settings, but you should be able to get the same effect by running:

echo -n publicbeta > ~/.steam/root/package/beta

and then launching Steam again.

I believe this is now fixed in the stable Steam client too.