[BUG] steamtours.sh will no longer start and prevents any other app from starting

[DomiStyle]

Describe the bug When starting SteamVR it will get stuck on the loading screen for SteamVR Home indefinitely. No other SteamVR applications will be able to start.

To Reproduce Steps to reproduce the behavior:

1. Start SteamVR
2. Wait

Expected behavior SteamVR Home to launch properly.

System Information (please complete the following information):

• Distribution: Fedora 38
• SteamVR version: 1.25.7
• Steam client version: Mar 24, 2023
• Opted into Steam client beta?: No
• Graphics driver version: Mesa 23.2.0-devel
• Gist for SteamVR System Information: https://gist.github.com/DomiStyle/d948fa9ef72337521af4d351ec64365a

Additional context Renaming steamtours.sh to steamtours.sh.old will allow other applications to launch.

Since there were so many updates this week through Fedora 38 (Mesa, KDE, ...) it's hard to say what caused it, it worked before.

Note: Commenters who are also experiencing this issue are encouraged to include the "System Information" section in their replies.

[kisak-valve]

Hello @DomiStyle, can you check if something similar to https://github.com/ValveSoftware/Dota-2/issues/2285 is happening here?

[DomiStyle]

Looks related, yes. When starting steamtours.sh manually:

Using breakpad crash handler
[S_API] SteamAPI_Init(): Loaded '/home/domi/.local/share/Steam/linux64/steamclient.so' OK.
Setting breakpad minidump AppID = 250820
Forcing breakpad minidump interfaces to load
Looking up breakpad interfaces from steamclient
Calling BreakpadMiniDumpSystemInit
Installing breakpad exception handler for appid(250820)/version(6733852)/tid(24297)
Looking up breakpad interfaces from steamclient
Calling BreakpadMiniDumpSystemInit
Steam_SetMinidumpSteamID:  Caching Steam ID:  76561198037034301 [API loaded yes]
Steam_SetMinidumpSteamID:  Setting Steam ID:  76561198037034301
src/tcmalloc.cc:390] Attempt to free invalid pointer: 0x564739f92570
crash_20230426165459_2.dmp[24309]: Uploading dump (out-of-process)
/tmp/dumps/crash_20230426165459_2.dmp
./steamtours.sh.old: line 94: 24297 Aborted                 (core dumped) ${STEAM_RUNTIME_PREFIX} ${GAME_DEBUGGER} "${GAMEROOT}"/${GAMEEXE} "$@"
[domi@domi-pc game]$ crash_20230426165459_2.dmp[24309]: Finished uploading minidump (out-of-process): success = yes
crash_20230426165459_2.dmp[24309]: response: CrashID=bp-2e372dbf-0855-4dbf-82bc-fd6ff2230426
crash_20230426165459_2.dmp[24309]: file ''/tmp/dumps/crash_20230426165459_2.dmp'', upload yes: ''CrashID=bp-2e372dbf-0855-4dbf-82bc-fd6ff2230426''

Here's the crash dump: crash_20230426165459_2.zip

[DomiStyle]

Fedora 38 also updated from LLVM 15 to LLVM 16 so might just be the same cause.

[kisak-valve]

Mesa git main from today should have the merge request mentioned at https://github.com/ValveSoftware/Dota-2/issues/2285#issuecomment-1517818053.

[DomiStyle]

Cool, will retest once the next Nobara Mesa build rolls along.

[DomiStyle]

I'm on Mesa 23.1.1 now, which should have these changes included but I still run into this issue.

The workaround listed on the Dota post does not seem to work with SteamVR either.

It also behaves differently between the Steam beta and without it. On the beta it gets stuck and fails with 109, on the regular Steam client it just hangs.

[farmboy0]

I recently installed LLVM 16 and mesa on Gentoo and run into the same bug. Mesa version is 23.1.2. Reverting back to LLVM 15 and rebuilding mesa with it fixed that problem.

[CorneliusCornbread]

I'm on Mesa 23.1.1 now, which should have these changes included but I still run into this issue.

The workaround listed on the Dota post does not seem to work with SteamVR either.

It also behaves differently between the Steam beta and without it. On the beta it gets stuck and fails with 109, on the regular Steam client it just hangs.

Be careful with Nobara's builds of Mesa, they will off and on lack the necessary extensions required to have VR work in any capacity. If you're having issues with SteamVR starting double check that Nobara's build of Mesa-Vulkan has the two following extensions (which have been missing in the past several times) VK_EXT_acquire_xlib_display VK_KHR_display

which can be checked with vulkaninfo | grep VK_EXTENSION_HERE

On a more general note I can confirm I'm having the same issue on Fedora 38, it will start and will actually display to the headset without issue but cannot start steamtours

[DomiStyle]

Be careful with Nobara's builds of Mesa, they will off and on lack the necessary extensions required to have VR work in any capacity.

I switched over to Fedora's regular Mesa builds a while ago, both extensions are present there.

The hacky workaround with renaming steamtours.sh still works though. The native version of Half-Life Alyx broke as well with Fedora 38 but Proton works.

[apcolvin]

Any idea when we will get a fix for this as I haven't had steam home for months now

[DomiStyle]

@apcolvin SteamVR Home works for me again with the latest SteamVR beta and Mesa. Not sure what fixed it but it starts just fine now.

[apcolvin]

Wish it did for me! What Mesa version do you have? My graphics are as follows: OpenGL vendor string: AMD OpenGL renderer string: AMD Radeon RX 5700 XT (navi10, LLVM 16.0.6, DRM 3.52, 6.4.11-1-default) OpenGL core profile version string: 4.6 (Core Profile) Mesa 23.1.5 OpenGL core profile shading language version string: 4.60

[DomiStyle]

I'm on Mesa 23.1.6 (git-0697ac0d75) on a 6900 XT with Flatpak Steam and the latest SteamVR (non-beta also works).

[apcolvin]

I am now on Mesa 23.1.17 and steamtours still crashes for me on opensuse tumbleweed so there is another reason for the crash than just the Mesa version

OpenGL vendor string: AMD OpenGL renderer string: AMD Radeon RX 5700 XT (navi10, LLVM 16.0.6, DRM 3.54, 6.5.3-1-default) OpenGL core profile version string: 4.6 (Core Profile) Mesa 23.1.7 OpenGL core profile shading language version string: 4.60

[DomiStyle]

Mine is broken again as well.

Doesn't block everything else from starting this time but SteamVR Home does not show on start. Half-Life Alyx in native is broken as well and I assume those issues are related since they always seem to break together. Proton still works.

[vermeeren]

With the new SteamVR 2 just being released I believe VR compositor itself is broken by this exact bug, so VR cannot be used at all until this is fixed. Downgrading to older Mesa with LLVM 15 makes SteamVR 2 work, with LLVM 16 I get #623 "Shared IPC compositor init failed".

Edit: This is #616 instead.

[DomiStyle]

Anything new on this? I haven't seen SteamVR Home in more than half a year now across dozens of SteamVR updates.

[DanielGaaA]

After replacing ~/.steam/steam/steamapps/common/SteamVR/tools/steamvr_environments/game/bin/linuxsteamrt64/libtcmalloc_minimal.so.0 with symlink to /usr/lib64/libtcmalloc_minimal.so.4 SteamVR Home will launch

[kisak-valve]

It looks like this is a minor variation of the issue being tracked at https://github.com/ValveSoftware/Source-1-Games/issues/5043 and there's a decent chance that https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=f50f2efae9fb0965d8ccdb62cfdb698336d5a933 is a mitigation for the issue, but it currently looks like that's lined up for libstdc++ built with gcc 14 + and that'll be a fair amount of time before it's commonly available on most systems.

EDIT: Linked commit is backported to libstdc++ 12 and 13 for their next point release (gcc 12.4 / 13.3).

[CertainLach]

https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=f50f2efae9fb0965d8ccdb62cfdb698336d5a933 will require SteamVR to be rebuilt with gcc 14 (As I can see, currently SteamVR is built with gcc 9.3.1, which is 4 years old), which will use posix_memalign instead of aligned_alloc.

And since SteamVR on linux support seems to be low priority, won't it be easier and faster for Valve to update tcmalloc/backport this commit instead? https://github.com/google/tcmalloc/commit/0abbbdefe12d3980c68d276ba8447fefb3c4163a

[DomiStyle]

Issue seems to finally be fixed on Fedora and SteamVR Home starts again.