[BUG] vrstartup crashes in IsRunningInAppContainer() on null pointer dereference

steamvropen bug

ValveSoftware/SteamVR-for-Linux#411 · opened 2020-12-13 by codewiz · updated 2022-01-22 · 4 comments · github

Ccodewiz 2020-12-13 github

Describe the bug

I can't start SteamVR (neither the beta nor the stable version). I tried starting it manually under gdb, and this is the backtrace:

bernie@goreboot:~[1]% gdb /home/bernie/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrstartup               
Reading symbols from /home/bernie/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrstartup...
(No debugging symbols found in /home/bernie/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrstartup)
(gdb) r
Starting program: /home/bernie/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrstartup
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[Detaching after vfork from child process 310939]
[Detaching after vfork from child process 310959]
...
Sun Dec 13 2020 20:26:22.393877 - vrstartup 1.15.12 startup with PID=310935, config=/home/bernie/.local/share/Steam/config, runtime=/home/bernie/.local/share/Steam/steamapps/common/SteamVR
Sun Dec 13 2020 20:26:22.393924 - vrclient type=VRApplication_Bootstrapper

Program received signal SIGSEGV, Segmentation fault.
std::string::compare (this=0x0, __s=0x7ffff6f7f2f7 "ID") at /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:1432
1432    /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc: No such file or directory.
(gdb) bt
#0  std::string::compare (this=0x0, __s=0x7ffff6f7f2f7 "ID") at /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:1432
#1  0x00007ffff6d01552 in IsRunningInAppContainer() () from /home/bernie/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrclient.so
#2  0x00007ffff6c9ac12 in CHmdSystemLatest::Init(vr::EVRApplicationType, char const*) () from /home/bernie/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrclient.so
#3  0x00007ffff7c40f42 in VR_InitInternal2 () from .local/share/Steam/steamapps/common/SteamVR/bin/linux64/libopenvr_api.so
#4  0x0000000000407bcf in RealMain(int, char**) ()
#5  0x0000000000409470 in main ()
(gdb)

To Reproduce
Steps to reproduce the behavior:

Fix bug #410
Then simply start SteamVR
See crash in the log

System Information (please complete the following information):
Distribution: Arch
SteamVR version: 1.15.14
Steam client version: Dec 11 2020
Opted into Steam client beta?: Yes
Graphics driver version: Mesa 21.0.0-devel (git-d7911f9c6b) (ACO)
Gist for SteamVR System Information: N/A

Ccodewiz 2020-12-13 github

In case it helps, here's an strace of the last actions prior to the crash:

read(5, "Name:\tvrstartup\nUmask:\t0022\nStat"..., 1024) = 1024
write(2, "Sun Dec 13 2020 20:36:45.035553 "..., 75Sun Dec 13 2020 20:36:45.035553 - vrclient type=VRApplication_Bootstrapper
) = 75
openat(AT_FDCWD, "/etc/os-release", O_RDONLY) = 6
read(6, "NAME=\"Arch Linux\"\nVERSION=\"2015."..., 8191) = 292
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
+++ killed by SIGSEGV (core dumped) +++
[2]    311918 segmentation fault (core dumped)  strace -f

BBaguettedood 2020-12-17 github

This was also reported in #390 which probably needs a title update.

Assuming it really is the same issue: As a summary, IsRunningInAppContainer() reads /etc/os-release to try and figure out if it's running in a container, but TokenizeString() returns some pairs of NULLs if there are blank lines in your /etc/os-release file, which IsRunningInAppContainer() then crashes on.

Until Valve does something about it, you can work around the issue by opening your /etc/os-release file and removing blank lines. Probably also remove newlines at the end of the file, if there are any.

Ccodewiz 2020-12-18 github

Deleting the empty line at the end of /etc/os-release fixed the crash for me. Thank you, @Baguettedood!

Uunlimitedbacon 2022-01-22 github

Sure enough, I'm on an old Antergos install migrated to Arch. It had a blank line in /etc/os-release and deleting it worked! Thanks, @Baguettedood.

Nothing extracted yet.