Steam crashes at launch with libgudev 238

camperboy1000 commented 1 year ago

Your system information

Steam client version (build number or date): 1687386907
Distribution (e.g. Ubuntu): Archlinux
Opted into Steam client beta?: No
Have you checked for system updates?: Yes
Steam Logs: steam-logs.tar.gz
GPU: AMD Radeon RX 570 8GB

Please describe your issue in as much detail as possible:

Arch Linux recently updated the libgudev and lib32-libgudev packages to version 238 in accordance with the release upstream. After updating, Steam crashes during launch. I have included the last couple lines before the crash below:

[...]
steamwebhelper.sh[32091]: glibc >= 2.34, partially disabling sandbox until CEF supports clone3()
CAppInfoCacheReadFromDiskThread took 144 milliseconds to initialize
Failed to init SteamVR because it isn't installed
Assertion 'device' failed at src/libsystemd/sd-device/device-private.c:103, function device_get_tags_generation(). Aborting.
crash_20230706184645_26.dmp[32280]: Uploading dump (out-of-process)
/tmp/dumps/crash_20230706184645_26.dmp
[...]

Downgrading libgudev and lib32-libgudev to version 237-2 works.

Steps for reproducing this issue:

Update libgudev and lib32-libgudev to version 238-1
Attempt to launch Steam
Steam aborts after updating and uploads a crash report

Temporary Workaround

Downgrading the libgudev and lib32-libgudev packages to version 237-2 is a temporarily workaround to get Steam to launch. The downgrade AUR package can be used to do this. Remember to update these packages when this issue is fixed.

Solutions

See this comment by devkarthin for a couple solutions.

kisak-valve commented 1 year ago

Hello @camperboy1000, Assertion 'device' failed at src/libsystemd/sd-device/device-private.c:103, function device_get_tags_generation(). Aborting. looks like it's coming from systemd, (https://github.com/systemd/systemd/blob/main/src/libsystemd/sd-device/device-private.c#L103), instead of Steam. I think this issue should also be reported to your distro's package maintainer(s) for systemd and/or libgudev.

Galcian79 commented 1 year ago

Same issue here

Proximus888 commented 1 year ago

Same here on Sway 1:1.8.1-1

Assertion 'device' failed at src/libsystemd/sd-device/device-private.c:103, function device_get_tags_generation(). Aborting.

Downgrading libgudev and lib32-libgudev to version 237-2 solves the issue.

RedstoneLP2 commented 1 year ago

Running into this issue myself I found this post on the Arch Forums. I'm unsure if removing lib32-libgudev has any adverse effects on steam/games, but it seems to be a solution in case nothing else depends on it

matthewarmand commented 1 year ago

For what it's worth, lib32-libgudev may be brought into some people's systems by Proton on Arch, which depends on it. So it may be a more significant issue for Proton, for whose users removing the package isn't an option. though it may also be that Steam itself is having problems when the library is installed

adi8900 commented 1 year ago

thanks, downgrading packages fixed my suddenly broken steam as well

GithubUser5462 commented 1 year ago

sudo pacman -U https://archive.archlinux.org/packages/l/libgudev/libgudev-237-2-x86_64.pkg.tar.zst
sudo pacman -U https://archive.archlinux.org/packages/l/lib32-libgudev/lib32-libgudev-237-2-x86_64.pkg.tar.zst
steam --reset

Got it working for me.

Edit: Actually it looks like the reset was enough, i updated libgudev and steam still works.

Galcian79 commented 1 year ago

In my case lib32-libgudev was a required dep of lib32-gst-plugins-good, which i don't really need anyway. Removing the package solved my issue.

matthewarmand commented 1 year ago

sudo pacman -U https://archive.archlinux.org/packages/l/libgudev/libgudev-237-2-x86_64.pkg.tar.zst
sudo pacman -U https://archive.archlinux.org/packages/l/lib32-libgudev/lib32-libgudev-237-2-x86_64.pkg.tar.zst
steam --reset
Got it working for me.

Edit: Actually it looks like the reset was enough, i updated libgudev and steam still works.

@GithubUser5462 are you saying you updated both libgudev and lib32-libgudev and it works? Or just libgudev? I don't think the reset has anything to do with it, I tried that and steam still breaks unless I downgrade lib32-libgudev specifically.

Downgrading libgudev as well doesn't seem functionally necessary, but I don't know if there are any prickly side effects from having the lib32 package on a different version than the main one.

Removal of the lib32 version isn't an option for me as I have Proton installed on my system.

Upstream issue filed for Arch's lib32-libgudev packager, as requested by @kisak-valve: https://bugs.archlinux.org/task/79006

GithubUser5462 commented 1 year ago

Yes i ran sudo pacman -Syu lib32-libgudev libgudev so version 238-1. I have two pc fully updated, steam is working fine on both. Weird. Maybe i had a different problem.

matthewarmand commented 1 year ago

On advice of Arch maintainers, issue opened upstream with libgudev: https://gitlab.gnome.org/GNOME/libgudev/-/issues/9

SunRed commented 1 year ago

I just experienced the same bug on a fully updated arch system with the latest steam beta, downgrading both libgudev and lib32-libgudev to version 237-2 works.

lucasoskorep commented 1 year ago

Can confirm that downgrading both libgudev and lib32-libgudev to version 237-2 works as well.

ghost commented 1 year ago

The package that had lib32-libgudev as dependency in my system was pronton-ge-custom-bin, removing it with pacman -Rs proton-ge-custom-bin solves this issue, in Arch. Beware of optional dependencies of other packages:

:: lib32-alsa-plugins benötigt optional lib32-libpulse: for conf_pulse, ctl_pulse and pcm_pulse plugins
:: lib32-sdl2 benötigt optional lib32-libpulse: PulseAudio audio driver
:: lutris benötigt optional lib32-vkd3d: DirectX 12 support
:: wine-staging benötigt optional lib32-gnutls
:: wine-staging benötigt optional lib32-libpulse
:: wine-staging benötigt optional lib32-libxcomposite
:: wine-staging benötigt optional lib32-libxinerama
:: wine-staging benötigt optional lib32-libva
:: wine-staging benötigt optional lib32-gtk3
:: wine-staging benötigt optional lib32-gst-plugins-base-libs

SunRed commented 1 year ago

To iterate on this further and to also reiterate what has been said on the respective issue trackers, the issue lies with Steam's runtime super old 32 bit version of libnm. Installing lib32-libnm so that Steam uses the system's libnm version instead fixes the issue for now.

devkarthin commented 1 year ago

After debugging for quite some time, here are my findings:

If you aren't interested in details, skip to the end for solutions.

The problem

The assertion fails because a member in the struct udev_device is NULL when it shouldn't be. This struct is an opaque pointer: its members can only be accessed by libudev. The only other libudev function this struct is passed to (besides the reference counting ones such as udev_device_ref()) is udev_device_new_from_subsystem_sysname(), called by g_udev_client_query_by_subsystem_and_name().

Placing a breakpoint at this function shows that calls to it use the Steam-provided version of libudev.

(gdb) bt
#0  0xec837c49 in udev_device_new_from_subsystem_sysname ()
   from /home/karthin/.local/share/Steam/ubuntu12_32/steam-runtime/lib/i386-linux-gnu/libudev.so.0
#1  0xeb6214a1 in g_udev_client_query_by_subsystem_and_name (client=0xe3828cd0, subsystem=0xe8dc77c8 "net", 
    name=0xe2db3190 "wlan0") at ../libgudev/gudev/gudevclient.c:507
#2  0xe8d55927 in ?? ()
   from /home/karthin/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libnm.so.0
#3  0xe8d56e40 in nm_device_get_vendor ()
   from /home/karthin/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libnm.so.0

However, calls to the function where the assertion fails, device_get_tags_generation(), use the system-provided version.

(gdb) bt
[...]
#5  0xeaa8476c in log_assert_failed (text=<optimized out>, file=<optimized out>, line=<optimized out>, 
    func=0xeaaa7608 <__func__.29.lto_priv.2> "device_get_tags_generation") at ../systemd-stable/src/basic/log.c:889
#6  0xeaa8d269 in device_get_tags_generation (device=<optimized out>)
    at ../systemd-stable/src/libsystemd/sd-device/device-private.c:103
#7  device_get_tags_generation (device=<optimized out>)
    at ../systemd-stable/src/libsystemd/sd-device/device-private.c:102
#8  udev_device_get_current_tags_list_entry (udev_device=0xdb950e10)
    at ../systemd-stable/src/libudev/libudev-device.c:863
#9  0xeba42fb5 in fetch_current_tags (device=0xdb950c90) at ../libgudev/gudev/gudevdevice.c:146
#10 _g_udev_device_new (udevice=udevice@entry=0xdb950e10) at ../libgudev/gudev/gudevdevice.c:163
#11 0xeba434af in g_udev_client_query_by_subsystem_and_name (client=0xdb95a100, subsystem=0xe91c77c8 "net", 
    name=0xe31ca2b0 "wlan0") at ../libgudev/gudev/gudevclient.c:511
#12 0xe9155927 in ?? ()
   from /home/karthin/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libnm.so.0
#13 0xe9156e40 in nm_device_get_vendor ()
   from /home/karthin/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libnm.so.0
[...]
(gdb) f 7
(gdb) info sym device_get_tags_generation
udev_device_get_current_tags_list_entry + 49 in section .text of /usr/lib32/libudev.so.1

The version provided by Steam is much, much older than the version provided by the system. These two versions are not ABI-compatible, hence the difference in soversion.

$ ls -l /home/karthin/.local/share/Steam/ubuntu12_32/steam-runtime/lib/i386-linux-gnu/libudev.so.0
lrwxrwxrwx 1 karthin karthin 17 Mar 23 12:06 /home/karthin/.local/share/Steam/ubuntu12_32/steam-runtime/lib/i386-linux-gnu/libudev.so.0 -> libudev.so.0.13.0
$ ls -l /usr/lib32/libudev.so.1
lrwxrwxrwx 1 root root 16 Jun  1 14:23 /usr/lib32/libudev.so.1 -> libudev.so.1.7.6

Solutions

Installing lib32-libudev0-shim
- Because of the order in LD_LIBRARY_PATH, Steam prefers dependencies provided by the system over its own. lib32-libudev0-shim installs a version of libudev.so.0 that loads libudev.so.1, so there will be no ABI-related issues.

Other solutions

Note that while these solutions do work, using them only avoids the issue. In the future, if another library were to use new libudev features not available in the version provided by the Steam runtime, you may run into ABI-related issues.

Installing lib32-libnm
- libnm makes calls to libgudev, which subsequently makes calls to libudev, causing the crash. Using a version of libnm provided by Arch, which has no dependency on libgudev, does not cause the crash.
Preloading/installing an older version of the libgudev
- Older versions do not call the failing function.
Uninstalling lib32-libgudev
- This makes Steam use the version of libgudev it provides.

StonyTark1117 commented 1 year ago

I had this issue today after upgrading as well. Arch/EndeavourOS with KDE. Downgrading the two libgudev packages mentioned by GithubUser5462 and doing a steam reset got it working for me.

caseyjp11 commented 1 year ago

Ditto for the update and then steam core dump. Downgrading libgudev packages resolved the problem here as well. (Well... band-aided it.)

GHNeko commented 1 year ago

Here are some solutions that worked for me. I have only tested these on Arch Linux:

1. Installing `lib32-libudev0-shim`
   Because of the order in `LD_LIBRARY_PATH`, Steam prefers dependencies provided by the system over its own. `lib32-libudev0-shim` installs a version of `libudev.so.0` that loads `libudev.so.1`, so there will be no ABI-related issues.

2. Installing `lib32-libnm`
   `libnm` makes calls to `libgudev`, which subsequently makes calls to `libudev`, causing the crash. Using a version of `libnm` provided by Arch does not cause the crash.

Did these two and it worked great.

On Vanilla Arch myself.

I tried to uninstall lib32-libgudev at first but I was stopped bercause proton-ge-custom was using it as a dependency. This issue showed for me first when I updated proton-ge-custom within the last 24 hours so maybe there is something to investigate there.

buzzkillingtonne commented 1 year ago

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/9805#issuecomment-1627611123

I found just installing libnm and lib32-libnm from the Arch repo fixed it, no need to downgrade or install anything else.

I'm running EndeavourOS.

evelikov commented 1 year ago

There is an Arch bug 75157 to add lib32-libnm/lib32-va as (opt)depends just over an year ago.

lazypool commented 1 year ago

I solved it after installing the lib32-libnm. The 'lib32-' prefix is necessary.

nskjelbred commented 1 year ago

Just uninstall lib32-libgudev, I am using Arch. yay -R lib32-libgudev

devkarthin commented 1 year ago

Hello everyone,

I've noticed that many people here are trying solutions such as uninstalling/downgrading lib32-libgudev or installing lib32-libnm. While these solutions may work for now, I wouldn't recommend them as long-term solutions. I have updated my comment with my reasoning.

evelikov commented 1 year ago

@devkarthin note that lib32-libudev0-shim should not be needed, if new(er) system components are used - components outside of the (old) Ubuntu based root, use dlopen(libudev.so.1), falling back to libudev.so.0.

While the Ubuntu based files are demoted (with some exceptions), when newer system libraries are found - as you have already noticed.

A while ago the Steam Runtime developer maintaining the library detection/promotion "greatly encouraged" that the Steam package would (opt)depends on lib32-libnm and friends. The bugs have been opened since alas :frowning_face:

caseyjp11 commented 1 year ago

I'll confirm that adding lib32-libnm resolved the issue for me. The updated libgudev files do not crash Steam with the addition.

eNTi commented 1 year ago

Installing lib32-libudev0-shim did not work for me on Artix Linux. Uninstalling lib32-libgudev did.

pfych commented 1 year ago

Confirming yay -Syu lib32-libnm fixed this issue for me

liberodark commented 1 year ago

same for me pacman -Syu lib32-libnm (have no revert libgudev)

BadBone2k commented 1 year ago

Installing lib32-libudev0-shim fixed it for me on Manjaro 23.0.0

ladsoftware commented 1 year ago

sudo pacman -U https://archive.archlinux.org/packages/l/libgudev/libgudev-237-2-x86_64.pkg.tar.zst
sudo pacman -U https://archive.archlinux.org/packages/l/lib32-libgudev/lib32-libgudev-237-2-x86_64.pkg.tar.zst
steam --reset
Got it working for me.

Edit: Actually it looks like the reset was enough, i updated libgudev and steam still works.

thanks. this fixed it for me.

ladsoftware commented 1 year ago

sudo pacman -U https://archive.archlinux.org/packages/l/libgudev/libgudev-237-2-x86_64.pkg.tar.zst
sudo pacman -U https://archive.archlinux.org/packages/l/lib32-libgudev/lib32-libgudev-237-2-x86_64.pkg.tar.zst
steam --reset
Got it working for me.

Edit: Actually it looks like the reset was enough, i updated libgudev and steam still works.

Downgrade is what fixed it for me.

i upgraded and reset but it didn't work.

so, downgrade is the only thing that works for me.

ghost commented 1 year ago

Confirming yay -Syu lib32-libnm fixed this issue for me

This also works for me.

folknor commented 1 year ago

Debian-based (EDIT: "Ubuntu" just for people searching) users can do sudo apt install libnm0:i386 which fixed it for me.

MathSquared commented 1 year ago

Confirming that I had this issue, which was resolved by installing lib32-libudev0-shim. I'm on Arch Linux.

sxiii commented 1 year ago

Same happend to me recently on Garuda Linux Soaring Raptor. Doing sudo pacman -S lib32-libudev0-shim indeed fixed it.

dataprolet commented 1 year ago

Uninstalling proton-ge-custom-bin worked for me

That "works" because it's also removing all dependencies of proton-ge-custom-bin, which includes lib32-libgudev.

Also everybody please don't comment on this issue with "confirming this or that worked for me". This has next to no value, simply upvote the respective comment.

Zorrototo commented 1 year ago

Friend of mine had the issue. Nothing in the thread fixed it for him. In the end on his computer there is no lib32-libnm or lib-gudev, because this is the current state of his computer after trying all the various combination of the "solutions" here, so here's mine: Totally random solution, it didn't fix anything as I can see my friend Steam log is nothing compared to my working Steam log, however he now can start and use steam. I did a steam --reset, then started Steam, which almost ALWAYS worked whatever workaround was applied (only the subsequent launch were guaranteed to not work after the reset), so in the first launch after the --reset I went into the Steam Settings, and I Enabled the GPU accelerated Rendering in web views. Subsequent Steam restart now works. All other subsequent restarts now work. But something is still very messed I feel, but it works for him now.

Zorrototo commented 1 year ago

The solution for my friend was to delete the folder ~/.cache/nvidia but only after deleting the folder ~/.nv which seemed to take precedence over the other. Seems like some GLCache issue related. This work with or without the setting for GPU accelerated rendering.

matthewarmand commented 1 year ago

Workarounds aside, what is the stance of Valve developers on this issue's actual solution?

This could be considered a packaging issue, where distro maintainers need to be aware of the correct compatibility packages or shims which need to be added to correctly package Steam (such as what has been suggested over at Arch with https://bugs.archlinux.org/task/75157, though based on comments here, there are also other affected distros).

It could also be considered a Valve tech-debt issue where Steam needs to be updated to modern versions of these libraries so that compatibility workarounds or packaging shims aren't necessary. Or, at the very least, documenting more openly what these dependencies are so that distro maintainers don't need to rely on reactively debugging issues to figure out what needs to be patched.

Valve devs have been relatively quiet on this issue since workarounds were reported, but it'd be useful for folks watching this issue to hear a substantive update on where this goes from here.

smcv commented 1 year ago

Workarounds aside, what is the stance of Valve developers on this issue's actual solution?

I'm not a Valve developer, but I help them with the Steam Runtime and packaging. If Valve developers are busy with other things (or on vacation, since it's that time of year), then I'm probably the best you're going to get in the short term.

This could be considered a packaging issue, where distro maintainers need to be aware of the correct compatibility packages or shims which need to be added to correctly package Steam (such as what has been suggested over at Arch with https://bugs.archlinux.org/task/75157, though based on comments here, there are also other affected distros).

tl;dr: Yes, there is a list of key libraries that packagers should add dependencies on. For various annoying technical reasons the Steam Runtime cannot reliably provide everything.

Valve's official packaging for the Steam client is https://repo.steampowered.com/steam/, which is intended to work on Ubuntu, and contains the "bootstrapper" that can be used to install the rest of Steam. As far as I'm aware, everyone who packages the Steam client bases their packaging in some way on that.

If you unpack the "source code" from https://repo.steampowered.com/steam/archive/stable/steam_latest-stable.tar.gz (currently version 1.0.0.78) and look in debian/control, you will see some lists of mandatory and optional dependencies in the steam-libs-amd64 and steam-libs-i386 stanzas; and in debian/changelog you can find the reasons why several of them are mandatory or optional dependencies (often written by me).

I would recommend that anyone packaging Steam for another operating system should pull in their operating system's equivalent of the packages listed in Valve's Steam bootstrapper packaging, with a similar strength of dependency. For example, in Ubuntu, steam-libs-i386 pulls in the libnm0:i386 package as a Recommends (a dependency that is installed by default, but can be removed if you specifically ask to remove it). The Arch equivalent is that in Arch, it should pull in lib32-libnm, either as a hard dependency or an optdepends (I'm not sure which, I don't know how "strong" an Arch optdepends is). This is not just because of dependency stack issues like this one, but also because libnm is more likely to be able to communicate successfully with a matching version of NetworkManager, and in the past we've seen crashes when sufficiently badly mismatched versions communicate.

I would also recommend that users of Debian/Ubuntu derivatives install the Recommends unless they have a good reason not to - they're all listed there and installed by default by a reason.

A known issue in the packaging of Valve's Steam bootstrapper is that steam-libs-amd64 and steam-libs-i386 are not mandatory dependencies of the steam-launcher package. They should be, but because of how Valve have historically documented the installation procedure for steam-launcher, it is not possible to make them mandatory at the packaging level; instead, a script run during Steam startup tries to install them. This is not ideal, but it's the best that can be done, given the historical constraints that exist. Please package as though steam-libs-amd64 and steam-libs-i386 were mandatory dependencies - they would be if we could do that.

Similarly, some of the dependencies in steam-libs-* are weaker than they should ideally be, because Valve's Steam bootstrapper aims to support old versions of Ubuntu where not all the packages existed. If you're packaging Steam for a specific newer distribution, then you can (and probably should) make some of the dependencies stronger.

With a different hat on, I'm a maintainer of Debian's steam-installer package, which is considered official by Debian but unofficial by Valve. steam-installer pulls in a list of libraries similar to the ones in Valve's Steam bootstrapper: in fact it's a somewhat longer list, and the dependencies are stronger.

Valve's Steam bootstrapper packaging does not currently have a dependency on libudev0 (which in Debian/Ubuntu contains the same code as Arch's lib32-libudev0-shim), but honestly it probably should have a Recommends. I'll look into that, but I'm not fully in control of the release schedule for the Steam bootstrapper (as I said, I'm not a Valve developer), so I can't give any specific timeline.

It could also be considered a Valve tech-debt issue where Steam needs to be updated to modern versions of these libraries so that compatibility workarounds or packaging shims aren't necessary.

I wish it was that easy! The 'scout' Steam Runtime included with Steam is constrained to contain only very old libraries, because it usually sets the minimum library versions for any OS that Steam can run on: for many of the included libraries, nothing older can be supportable, however much Valve might want to support it. This is particularly problematic for older "LTS" distributions (I believe Ubuntu 16.04 is currently the minimum), or for derivatives based on an older LTS distribution (for example the latest release of Linux Mint is often based on an older-than-current Ubuntu LTS release).

For a few higher-level libraries with "nice" version numbering (like SDL), it is possible to include backports in the Steam Runtime, and we do; but for lower-level libraries we often can't.

The libnm in scout is already a backport of a somewhat more modern version (from Debian 9, according to my notes), and is probably the most modern version that's feasible to include: when working on a 10+ year old base, the dependency chains for other backports quickly become prohibitive.

libudev is likely to be one of the difficult ones to backport because of its history: the SONAME break from libudev.so.0 to .so.1, the transition from independent project to part of systemd, and the forked version in libeudev. All of those are factors that make it more likely to be non-backportable.

One possible route that might be taken in future versions of Steam is moving some of its functionality into a container, similar to how Proton games are handled, which would allow the container to have a more modern library stack (the ones used for Proton are based on Debian 10 and 11) without breaking compatibility with older host OS distributions. That comes with its own compatibility and complexity headaches, but at some point it's going to become necessary anyway. I don't know whether the parts that communicate with NetworkManager would be candidates for that treatment, but I hope so!

Or, at the very least, documenting more openly what these dependencies are so that distro maintainers don't need to rely on reactively debugging issues to figure out what needs to be patched.

I don't control what documentation Valve offers, so I can't help you with that. The dependency lists in the Steam bootstrapper are the closest thing there is to a canonical dependency list right now.

matthewarmand commented 1 year ago

Thanks for an incredibly detailed response. I'm sure there will be much more discussion soon but just one quick point for now (emphasis mine):

For example, in Ubuntu, steam-libs-i386 pulls in the libnm0:i386 package as a Recommends (a dependency that is installed by default, but can be removed if you specifically ask to remove it). The Arch equivalent is that in Arch, it should pull in lib32-libnm, either as a hard dependency or an optdepends (I'm not sure which, I don't know how "strong" an Arch optdepends is).

From the mighty Wiki (emphasis mine) (https://wiki.archlinux.org/title/PKGBUILD#optdepends):

An array of packages that are not needed for the software to function, but provide additional features. This may imply that not all executables provided by a package will function without the respective optdepends. If the software works on multiple alternative dependencies, all of them can be listed here, instead of the depends array.

optdepends dependencies aren't installed alongside the package by default. If they're brought in by another package (say package-a), and a user recursively removes package-a and its dependencies (pacman -Rs package-a), the dependency will be kept on the machine. If a user explicitly removes the dependency, pacman will allow the removal (while printing a warning about the optional dependency).

This sounds mostly similar to "Recommends" except that it's not installed by default. However it also seems like an anti-pattern where the optional dependencies are sometimes functionally necessary as opposed to just enabling optional features. At any rate, this is being discussed across several Arch Linux issues including the one I linked previously.

smcv commented 1 year ago

That sounds to me as though Arch optdepends are more like apt's Suggests (perhaps a little stronger than Suggests, but definitely weaker than Recommends), and that's really too weak for a lot of the libraries Steam benefits from.

where the optional dependencies are sometimes functionally necessary as opposed to just enabling optional features

The problem here is that in principle, the Steam Runtime provides nearly everything Steam needs, making an equivalent library at OS level merely a nice-to-have that might have more features or fewer bugs - but because certain combinations of newer libraries will crash, we can easily get dependency relationships that aren't even representable by common package managers, like "if you have libfoo >= 3 then you also need libbar".

thankjura commented 1 year ago

Same problem on gentoo. After rebuild networkmanager with abi_x86_32 flag problem disappeared

smcv commented 1 year ago

After rebuild networkmanager with abi_x86_32 flag problem disappeared

If this installs a 32-bit (i386) version of libnm.so.0, then that's exactly Gentoo's equivalent of installing libnm0:i386 on Debian/Ubuntu or lib32-libnm on Arch.

smcv commented 1 year ago

Installing lib32-libudev0-shim

Because of the order in LD_LIBRARY_PATH, Steam prefers dependencies provided by the system over its own. lib32-libudev0-shim installs a version of libudev.so.0 that loads libudev.so.1, so there will be no ABI-related issues.

In principle this should be the good workaround, but unfortunately, this is not completely true: archlinux/libudev0-shim#4 prevents that from working the way it should in distros that package this shim (at least Arch, Debian and Ubuntu, possibly others).

The Steam Runtime cannot unconditionally prefer dependencies provided by the system, because part of the purpose of the Steam Runtime is being able to run Steam and Steam games on older "LTS" distributions such as Debian stable/oldstable, Ubuntu LTS and the RHEL/CentOS family, and it sometimes provides backported libraries that are newer than the versions in the oldest OS that is supported (notably SDL). When that happens, the Steam Runtime must detect it, and use its own backported library if necessary - but we can only do that if the versions compare in the intended order.

I'm going to look into whether we can work around this in the Steam Runtime, but it would be nice to fix this upstream in Arch's libudev0-shim rather than having to work around it.

Gentoo has a slightly different libudev.so.0 shim and that one should work OK, because if the Steam Runtime can't identify whether a library is older or newer (in particular if no symlinks are involved at all), then it prefers the host OS copy.

smcv commented 1 year ago

Until the issues with libudev.so.0 version comparison are resolved, the workaround I would suggest as most likely to be reliable is to install a 32-bit libnm.so.0 (lib32-libnm on Arch, libnm0:i386 on Debian/Ubuntu, or whatever is the closest equivalent on other OSs). Having this library at the OS level has solved other Steam crashes in the past (when an older libnm has trouble talking to a new NetworkManager) so it's a good idea in general, whether this issue is solved differently or not.

In some environments it might also be necessary to install a 32-bit libusb-1.0.so.0 (lib32-libusb on Arch, libusb-1.0-0:i386 on Debian/Ubuntu, or your OS's equivalent). That's the other library in the Steam Runtime, apart from libnm.so.0, that could pull in libudev. (You might have this already as a dependency of something else.)

I'm looking at possible solutions for this on the Steam Runtime side, but if it's solvable from there then it will take some time.

smcv commented 1 year ago

I'm looking at possible solutions for this on the Steam Runtime side, but if it's solvable from there then it will take some time.

We've been able to backport a somewhat more recent libudev for the Steam Runtime while maintaining compatibility with older distributions and eudev, so a future Steam beta will hopefully resolve this. Having both 64- and 32-bit system copies of libudev.so.1 from 2015 or later is recommended: the minimum would be systemd v215 or eudev v1.9, but newer would be better. If present, the runtime will prefer to use those instead of its own fallback version.

Until then, the workaround that I'd recommend is as described in my previous comment: install a 32-bit system copy of libnm.so.0, and if that doesn't resolve the crash, try doing the same for libusb-1.0.so.0.

wold9168 commented 1 year ago

I installed lib32-libnm and the problem was solved. By the way, I haven't installed lib32-libudev0-shim. And I don't install the Proton-GE from archlinuxcn or aur, but from the official repository.

Sorry for my poor English.

guimaluf commented 1 year ago

on Gentoo I've fixed with

echo sys-libs/libudev-compat abi_x86_32 > /etc/portage/package.use/steam
emerge -vq  sys-libs/libudev-compat

ValveSoftware / steam-for-linux