Steam client version (build date): 2022-06-18 00:17:34
Distribution: Voidlinux
Opted into Steam client beta?: No
System updates?: Yes
Please describe your issue in as much detail as possible:
Steam client (and SteamVR for that matter) do not cope with certain contents (not) found in the particular /etc/os-release found on my system. After some sleuthing I figured out, that given the /etc/os-release file I have here, eventually a nullptr is being dereferenced somewhere in the code that processes this file. I didn't manage to capture proper backtrace for the Steam client crash, but a practically identical crash happens when starting the SteamVR solo (heck, it might even be due to the Steam client dynamically loading SteamVR libraries). Unfortunately I only have the screenshot of the backtrace (forgot to dump it to a textfile)
By denying access to /etc/os-release (either by changing its permission bits, or outright removing it) this bug no longer triggers.
As an interim workaround I implemented a small tool that simply replaces all occurances of /etc/os-release with a string of NUL bytes of the same length in all ELF files found in the Steam client installation tree. That's quite the nuclear option, but at least it gets things working for me.
Steps for reproducing this issue:
Put the contents of the particular /etc/os-release I've attached into the system's /etc/os-release
Start the Steam client (or SteamVR standalone)
Watch it crash inside libstdc++.so attempting to dereference a nullptr, that has been passed by a calling function.
Your system information
Please describe your issue in as much detail as possible:
Steam client (and SteamVR for that matter) do not cope with certain contents (not) found in the particular
/etc/os-releasefound on my system. After some sleuthing I figured out, that given the/etc/os-releasefile I have here, eventually anullptris being dereferenced somewhere in the code that processes this file. I didn't manage to capture proper backtrace for the Steam client crash, but a practically identical crash happens when starting the SteamVR solo (heck, it might even be due to the Steam client dynamically loading SteamVR libraries). Unfortunately I only have the screenshot of the backtrace (forgot to dump it to a textfile)By denying access to
/etc/os-release(either by changing its permission bits, or outright removing it) this bug no longer triggers.As an interim workaround I implemented a small tool that simply replaces all occurances of
/etc/os-releasewith a string of NUL bytes of the same length in all ELF files found in the Steam client installation tree. That's quite the nuclear option, but at least it gets things working for me.Steps for reproducing this issue:
/etc/os-releaseI've attached into the system's/etc/os-releaselibstdc++.soattempting to dereference a nullptr, that has been passed by a calling function.