The steam client version is 1601512230

I'm surprised to see libstdc++.so.6 in the pinned libraries there. Even if CentOS 7 is pretty old (2014), I would expect the host to have a newer version that doesn't require pinning scout's version before it. Could be unrelated though.

Bear in mind that run.sh is not always amazingly good at determining which version of a library is newer and which one is older (pressure-vessel has per-library knowledge for this sort of thing, although libstdc++ is not currently one of the special cases).

What's in the RPM that contains libstdc++.so.6 on this OS? I'd be particularly interested to see the result of ls -l /usr/lib64/libstdc++.so.* (or whatever directory it's really in).

Even if CentOS 7 is pretty old (2014), I would expect the host to have a newer version that doesn't require pinning scout's version before it

Actually... scout originally had libstdc++ from gcc 4.6, but has been upgraded to the version from gcc 5. CentOS 7 appears to have gcc 4.8. So perhaps scout's libstdc++ is genuinely newer than the copy in the host OS in this case.

in std::string::compare(char const*) const ()

This seems reasonably likely to be a NULL pointer dereference (like most crashes in strcmp). Does IsRunningInAppContainer in vrclient definitely check for NULL strings?

Many thanks for your help.
Just wanted to mention that SteamVR was working fine on CentOS 7 before the last update.

ls -l /usr/lib64/libstdc++.so.*
lrwxrwxrwx 1 root root 19 Apr 15 07:51 /usr/lib64/libstdc++.so.6 -> libstdc++.so.6.0.19
-rwxr-xr-x 1 root root 991616 Aug 6 2019 /usr/lib64/libstdc++.so.6.0.19

Okay, through a lot of trial-and-error and reverse-engineering, I think I've figured it out.

The function IsRunningInAppContainer() tries to determine if SteamVR is running in a container by reading the contents of /etc/os-release, I believe to check if ID=steamrt. But, for some reason, it reads the wrong bits of the file if there are any empty lines in /etc/os-release, resulting in the segfault. Possibly an issue with TokenizeString() converting the whitespace lines and returning entries that just contain nulls?

To the end-users until this crash gets fixed: Check the file /etc/os-release and remove any blank lines. The file should not end on a new line. It should end on the same line as the last parameter. Make a backup of the file in advance, of course. You may need to start your text editor with sudo e.g. sudo nano /etc/os-release.

To Valve: You should be able to reproduce this crash yourself by adding some trailing newlines at the end of your /etc/os-release file, and then hopefully figure out whatever makes SteamVR read the wrong lines. If you still can't reproduce, let me know and I can send you my version before removing the empty lines.

Edit: A quick check of the /etc/os-release file in CentOS 7 confirms it also has a few blank lines in its initial state. Other distros might too but I have not tested them all. If your distribution has empty lines in its /etc/os-release by default, feel free to comment.

Edit 2: EndeavourOS (arch-derived) also has a newline at the end of the file by default, which is perfectly normal for a /etc/os-release file to have.

Just hit this bug on my old Antergos Linux (Arch)
Removed new lines from /etc/os-release did allow Steam VR to boot fine.

I've been without VR for months on Void Linux. I can confirm that removing the single blank line from /etc/os-release has fixed the segfault problem. Thanks so much for working out this simple fix!

The function IsRunningInAppContainer() tries to determine if SteamVR is running in a container by reading the contents of /etc/os-release, I believe to check if ID=steamrt

As a note to the SteamVR developers within Valve:

If your goal with this is to detect whether SteamVR is running inside SteamLinuxRuntime (also known as the Steam container runtime or pressure-vessel), there is now an easier way to achieve the same thing with less parsing: you can try to read /run/host/container-manager, which is a filename borrowed from systemd's container interface. All versions of the Steam container runtime since early 2021 have created this file.

If it contains pressure-vessel followed by a newline, then you're running under pressure-vessel. If it contains flatpak followed by a newline, then you're running under Flatpak 1.10 or later. If it contains some other string, you're running under some other container manager (other high-level container managers like Toolbx and other app-sandboxing frameworks like Snap might implement the same interface now or in future, I don't know exactly what the status is). If the file doesn't exist, you're running on the host system or in a container manager that doesn't support this interface.

If your goal is to detect a specific major version of the container runtime (for instance distinguishing between scout, soldier and sniper containers), parsing os-release is still the easiest way to achieve that.