Steam crashes at launch with libgudev 238

[camperboy1000]

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:

1. Update libgudev and lib32-libgudev to version 238-1
2. Attempt to launch Steam
3. 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]

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]

Same issue here

[Proximus888]

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]

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]

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]

thanks, downgrading packages fixed my suddenly broken steam as well

[GithubUser5462]

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]

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]

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]

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]

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

[SunRed]

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]

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

[ghost]

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]

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]

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]

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]

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

[GHNeko]

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]

Replying to #9805 (comment)

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]

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

[lazypool]

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

[nskjelbred]

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

[matthewarmand]

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]

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]

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

[smcv]

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]

• 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]

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]

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]

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]

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

[MathSquared]

I commented above that my Steam was working with lib32-libudev0-shim, but it stopped working today. (I didn't update my system before it broke, but I think Steam updated itself.)

I installed lib32-libnm (lib32-libusb was already installed) and that fixed the issue.

[evelikov]

@MathSquared the Arch shim has a bug that would prevent if from working reliably see archlinux/libudev0-shim#4. It also has a secondary issue, which you might exhibit if you rebuild it archlinux/libudev0-shim#3

Not much we can do about either - it's up-to the Arch devs to press the Merge button.

[chewi]

Is this actually still an issue? I added 32-bit "libudev0" as a dependency on Gentoo to address this yesterday, but now a user tells me the problem had already gone away in the mean time. I build most things with 32-bit, so I haven't been able to tell myself.

[smcv]

Is this actually still an issue?

"It's complicated". Whether it is an issue depends on the exact combination of libraries that you have installed on the host system, and on how lucky you have been. I would recommend that packagers should include a solution or workaround on the packaging side: typically the workaround will be low-effort and make the package work considerably more reliably, reducing the number of bug reports that the packager receives, which seems like a good deal to me.

As I said in #9805 (comment), a solution to this on the Steam Runtime side is in the pipeline and will hopefully be in a future Steam beta. I don't have control over Steam's release cycle, so I can't predict when this will happen. If all goes well, when this change has got all the way through the release pipeline to stable status, it will make the workarounds unnecessary (but also harmless, so there will be no need to rush to remove them).

I added 32-bit "libudev0" as a dependency on Gentoo to address this yesterday

Thank you, I think that is an appropriate change for Gentoo packaging. Gentoo's libudev0 shim is not installed in exactly the same way as Arch's (it doesn't suffer from archlinux/libudev0-shim#4), so I think this will act as a reliable workaround on Gentoo specifically (but not for anyone else).

Non-Gentoo-based distributions that have a shim version of libudev0 implemented in terms of libudev1 tend to use the one that originated in Arch - for instance that's what we have in Debian. This is not (yet!) a reliable workaround as long as archlinux/libudev0-shim#3 and archlinux/libudev0-shim#4 are unfixed: archlinux/libudev0-shim#3 is fixed in Debian but not in Arch, and archlinux/libudev0-shim#4 is not fixed anywhere. The changes that are queued for a future Steam beta include a workaround for archlinux/libudev0-shim#4 which should make this more reliable.

For users of non-Gentoo-based distributions like Arch, Debian and Ubuntu, my recommendation is still #9805 (comment). For example, in Debian's steam-installer package, I upgraded libnm0:i386 from Recommends to Depends and added libusb-1.0-0:{amd64,i386} to Recommends.

[smcv]

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.

This change arrived in yesterday's Steam client beta release (1692041866, 14 August 2023), which should work correctly even without the workarounds that I previously recommended. In the fixed version, ~/.steam/root/ubuntu12_32/steam-runtime/version.txt should say 0.20230801.56012 or later.

I would still recommend that packagers of the Steam client should give it at least a weak/optional dependency on 32-bit libnm.so.0 (Debian/Ubuntu: libnm0:i386, Arch: lib32-libnm, or your distribution's equivalent). As I said before, even if it isn't necessary for this crash, we've seen crashes with previous Steam releases that could be resolved by upgrading the 32-bit libnm.so.0 to a version that matches the installed version of NetworkManager. In Debian, I used Recommends, which is an optional dependency that is installed by default but can be removed by the user: I think that's an appropriate strength of dependency to use here.

The changes that are queued for a future Steam beta include a workaround for archlinux/libudev0-shim#4 which should make [using Arch's libudev0-shim] more reliable

This change was ValveSoftware/steam-runtime@2677a6e and is also included in yesterday's Steam client beta (1692041866, 14 August 2023).

[puleglot]

Is this actually still an issue? I added 32-bit "libudev0" as a dependency on Gentoo to address this yesterday, but now a user tells me the problem had already gone away in the mean time. I build most things with 32-bit, so I haven't been able to tell myself.

Yes. I had this issue after upgrading to libgudev-238. Installing sys-libs/libudev-compat fixed it for me.
Building net-misc/networkmanager with USE=abi_x86_32 probably would also work.

[PagnuM]

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

This solved the problem for me, I'm using the latest packages too.

[smcv]

Removing lib32-gudev is a workaround, not a good solution for this.

As said above, the good solution is now included in the Steam client beta branch, and will ship in the stable (general-availability) branch at some point in the future (I cannot predict a timeline for this, it depends what is happening in unrelated Steam development topics).

If you cannot use the beta for whatever reason, better workarounds can be found in #9805 (comment).

[smcv]

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.

This change arrived in yesterday's Steam client beta release (1692041866, 14 August 2023) ... In the fixed version, ~/.steam/root/ubuntu12_32/steam-runtime/version.txt should say 0.20230801.56012 or later.

This updated runtime is now included in the general-availability (default, stable, non-beta) version of the Steam client. @kisak-valve, if there is no negative feedback in the next few days, I think we can close this issue.

I don't see any release notes for this update in the usual place yet; the change seems to have gone out unannounced.

The workaround mentioned in #9805 (comment) should no longer be needed, but it's harmless and might prevent unrelated crashes, so I would still recommend it to distros/packagers.

[kisak-valve]

Closing as fixed in the 2023-09-11 Steam client update.