Dota 2 fails to launch on Solus due to ld.so.conf path

[Horb]

Your system information

• System information from steam (Steam -> Help -> System Information) in a gist: https://gist.github.com/Horb/847d6691ad42f0c855d223e48ab32ced
• Have you checked for system updates?: Yes
• Are you using the latest stable video driver available for your system? Yes
• Have you verified the game files?: Yes

Please describe your issue in as much detail as possible:

Describe what you expected should happen and what did happen. Please link any large pastes as a Github Gist.

Dota 2 does not launch from Steam. My current work around is to run dota2.sh manually but this doesn't setup the Steam Overlay which I need for purchases.

See attached steam_output.txt and the segfault on line 86.

Steps for reproducing this issue:

1. Select Dota 2 in my Steam Library.
2. Click PLAY
3. See typical Steam dialogs (Synchronizing Steam Cloud etc.), PLAY button turns to STOP.
4. Dota 2 does not launch as expected. STOP button returns to PLAY.

[kisak-valve]

Hello @Horb, it looks like you or your distro is disabling the Steam runtime. This is unsupportable. I'm guessing it's from a setting in Solus's Linux Steam Integration utility. Can you deselect the Use native runtime setting in that utility, restart Steam, and see if it has an effect?

[Horb]

I've been toggling options in that utility all day :upside_down_face:

It's the same result with Use native runtime deselected. Segfault on line 125 here; steam_output.txt

[kisak-valve]

This is a blind guess, but can you verify the integrity of Steam Linux Runtime's files in Steam?

[Horb]

Should that be a short process? It's just stuck like this for 15 minutes?

[kisak-valve]

In a quick test, it took a couple seconds here.

[Horb]

Something amiss there then. I've completely reinstalled Steam today as well.

It's late here I'll check back in tomorrow.

Is there a utility I can use to get a better log or trace for you?

On Wed, 4 May 2022, 23:46 kisak-valve, @.***> wrote:

In a quick test, it took a couple seconds here.

— Reply to this email directly, view it on GitHub https://github.com/ValveSoftware/steam-runtime/issues/510, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATJF2O25MR27HYPSI2DVKLVIL42ZANCNFSM5VC6FZ6A . You are receiving this because you were mentioned.Message ID: @.***>

[Horb]

Verifying the tools worked today. It took a few seconds to verify the integrity of both the Steam Linux Runtime and the Steam Linux Runtime - Soldier.

The issue with Dota 2 still remains.

Line 151 here; steam_output.txt.

[smcv]

Please try the procedure described in https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md#essential-information:

• Completely exit from Steam
• Run Steam from a terminal, with environment variable STEAM_LINUX_RUNTIME_LOG=1 (so the full command is something like STEAM_LINUX_RUNTIME_LOG=1 steam)
• Get the Help -> System Information again, so that we have a matching set of information with it all coming from the same configuration (it gets really confusing if you're trying multiple configuration options and the debug information we have is from different sessions)
• Try to launch Dota 2
• Get the log from SteamLinuxRuntime_soldier/var/slr-latest.log

This will give us more information about how the libraries on your system compare with the libraries in the container.

Additionally adding PRESSURE_VESSEL_VERBOSE=1 and/or CAPSULE_DEBUG=tool might also be useful.

var/steam-runtime/lib/i386-linux-gnu/libgcc_s.so.1: version `GCC_7.0.0' not found (required by /tmp/pressure-vessel-libs-01D0L1/i686/libstdc++.so.6)

This indicates that the container tool is correctly loading a newer libstdc++.so.6 from the host system, but is not picking up the libgcc_s.so.1 that should go with it. Either there's a bug in the container tool, or Solus' "Steam integration" is interfering with normal operation of the container tool.

[Horb]

Recreated this reply because my system information was incomplete.

I ran;

PRESSURE_VESSEL_VERBOSE=1 CAPSULE_DEBUG=tool STEAM_LINUX_RUNTIME_LOG=1 steam

System Information: https://gist.github.com/Horb/5754c7f9a4001e3235f4bc2fd8a9ea45 slr-latest.log: https://gist.github.com/Horb/4a7cbc915786ac15a816a94977c6a63c

[smcv]

Looks like Steam was run with:

    "LD_PRELOAD=/usr/$LIB/libxcb.so.1:/usr/$LIB/libX11.so.6:/usr/$LIB/libstdc++.so.6",

forcing it to use the system copy of those libraries.

I'll have to look into what is meant to happen when this case is combined with containers: it's quite a corner-case situation. The problem might be that the pressure-vessel container tool tries to do as you say, even if it's harmful to do so.

[anko]

I believe I have the same issue. (With Steam Play enabled, Dota 2 won't start. It works with Steam Play disabled.)

As a second data point, I collected logs as per @smcv's comment: they're in this gist along with Steam system information.

[smcv]

@anko: I think you have a different issue. Please report it separately to https://github.com/ValveSoftware/steam-runtime/ to avoid getting the root cause of this one confused.

@kisak-valve: perhaps you could retitle this one to "fails to launch on Solus due to /usr/$LIB/libstdc++.so.6 in LD_PRELOAD" or something, to narrow down the scope?

[smcv]

I'll have to look into what is meant to happen when this case is combined with containers: it's quite a corner-case situation.

The problem is that when people use something like LD_PRELOAD=/usr/$LIB/libMangoHud.so mygame, they expect MangoHud to be "captured" from the host system into the container; but when people use something like LD_PRELOAD=libSDL-2.0.so.0, grabbing more libraries from the host system into the container would undermine what the container runtime is trying to do, which is to provide a predictable runtime environment with known-good libraries that make the game work.

We have a heuristic that can filter out LD_PRELOAD=libstdc++.so.6 to stop it breaking things, but it doesn't currently work for LD_PRELOAD=/path/to/libstdc++.so.6.

However, looking more carefully at the latest log from @Horb, it seems there are two separate problems here:

• Dota 2 crashes with a segmentation fault, possibly similar to what @anko reported.
• After that crash, unlike @anko's report, the crash-report uploader crashes (!) as a result of some weirdness involving LD_PRELOAD.

@Horb, perhaps you could try running Dota 2 with these launch options?

env -u LD_PRELOAD %command%

It might still crash - but if it does, I'm hoping it will be able to upload its crash report (like it did for @anko) so that Dota developers can look at where it's crashing.

I've been toggling options in [Solus's Linux Steam Integration utility] all day

In general we can't really support running Steam or games with distro workarounds applied: for every problem solved by applying those workarounds globally, another problem is caused. The situation that game developers are most likely to be able to debug is having as few workarounds applied as possible, preferably none.

I recognise that if a game developer is unable to solve something, it can become necessary to apply local workarounds, but they're often counterproductive when trying to find a non-workaround solution to a problem.

[smcv]

Note that env -u LD_PRELOAD %command% will disable the Steam overlay, which means that some Steam features will not work, including Remote Play, Steam Input, and the overlay itself; so you probably shouldn't use that long-term. However, I'm hoping that it will at least help to get a crash report uploaded...

[Horb]

Launched steam with; PRESSURE_VESSEL_VERBOSE=1 CAPSULE_DEBUG=tool STEAM_LINUX_RUNTIME_LOG=1 steam, and set my Dota 2 launch options to; env -u LD_PRELOAD %command%. Pressed play and reproduced the issue.

Steam System Information: https://gist.github.com/Horb/3895c35611743550d0caf3cb40cb153b slr-latest.log: https://gist.github.com/Horb/450288862875a9d3faf2a69d3fbdbfa9

[Horb]

In general we can't really support running Steam or games with distro workarounds applied: for every problem solved by applying those workarounds globally, another problem is caused. The situation that game developers are most likely to be able to debug is having as few workarounds applied as possible, preferably none.

I'll try and find out if there's a way to remove Solus's Linux Steam Integration utility. At the moment I think they have it as a dependency of their steam package.

[smcv]

Looks like the crash report was uploaded successfully this time:

crash_20220511145515_2.dmp[9762]: file ''/tmp/dumps/crash_20220511145515_2.dmp'', upload yes: ''CrashID=bp-f00ba326-3fd8-4b30-bd5e-a247b2220511''

but I don't have access to the crash reporting system, so a Dota developer will have to take over investigating this.

[JacekJagosz]

I have created an issue at Solus' bugtracker: https://dev.getsol.us/T10265

[JacekJagosz]

I have patched it on Solus, so that when Native Runtime is disabled nothing is added to LD_PRELOAD, and yet @Horb has reported it is still happening to him. So the issue must be something else, now there are no distro-specific hacks that Solus does with native runtime set to off.

[smcv]

As I said in https://github.com/ValveSoftware/steam-runtime/issues/510, I think the LD_PRELOAD thing was breaking the automatic crash reporter, but not the game itself. Hopefully now that the automatic crash reporter works, a Dota 2 developer can inspect the automatic crash reports and use them to get more clues about why the game is crashing.

[TTimo]

We do not keep the crash dumps on our servers for very long, please reproduce and post an id for a successful upload..

[Horb]

slr-latest.log: https://gist.github.com/Horb/19be9d6dfea1c64690cc5d77b85a20ef System Information: https://gist.github.com/Horb/e8604e82bbcb45d1808b05b0e74322f2

I think the id is CrashID=bp-f00ba326-3fd8-4b30-bd5e-a247b2220511 based on this snippet from the above log;

/home/adam/.local/share/Steam/steamapps/common/dota 2 beta/game/dota.sh: line 109:  9748 Segmentation fault      (core dumped) ${STEAM_RUNTIME_PREFIX} ${GAME_DEBUGGER} "${GAMEROOT}"/${GAMEEXE} "$@"
14:55:15.779079: pressure-vessel-adverb[9683]: D: Child 9707 exited with wait status 35584
14:55:15.779187: pressure-vessel-adverb[9683]: I: Command exited with status 139
crash_20220511145515_2.dmp[9762]: Finished uploading minidump (out-of-process): success = yes
crash_20220511145515_2.dmp[9762]: response: CrashID=bp-f00ba326-3fd8-4b30-bd5e-a247b2220511
crash_20220511145515_2.dmp[9762]: file ''/tmp/dumps/crash_20220511145515_2.dmp'', upload yes: ''CrashID=bp-f00ba326-3fd8-4b30-bd5e-a247b2220511''

[TTimo]

can you upload the crash_*.dmp files directly maybe. I'm not very familiar with dota 2's setup, and despite what the log says, it seems our servers still don't have the crash dumps :(

[Horb]

slr-latest.log crash_20220528171240_2.txt steam_system_information.txt

I may have uploaded a stale slr-latest previously and that's why you couldn't find the crash log. Try CrashID=bp-fa56cd10-4560-4196-8a0a-46eda2220528

I had to rename the .dmp fule to .txt so I could upload it here.

[TTimo]

This crash did upload successfully. The error on the dota2 side is that SDL_CreateWindow failed (SDL_WINDOW_OPENGL | SDL_WINDOW_HIDDEN). The actual error message dota2 gives in this case being Unable to create dummy window for GLMDisplayDB.

I still see in the SLR logs indications that libstdc++ and libgcc_s are mismatched though. Dota2 still manages the upload, but that's probably not very good overall:

/tmp/dumps/crash_20220528171240_2.dmp: /home/adam/.local/share/Steam/steamapps/common/SteamLinuxRuntime/var/steam-runtime/lib/i386-linux-gnu/libgcc_s.so.1: version `GCC_7.0.0' not found (required by /tmp/pressure-vessel-libs-6LJ2M1/i686/libstdc++.so.6)
ERROR: Could not run steamerrorreporter binary. Uploading minidump in-process
Uploading dump (in-process) [proxy '']

[smcv]

required by /tmp/pressure-vessel-libs-*/i686/libstdc++.so.6

This is the smoking gun that says libstdc++.so.6 was in LD_PRELOAD.

[TTimo]

I worked through the crash reports some more, and the SDL_CreateWindow abort is seen for a bunch of different systems, no particular distro, I see arch, fedora etc. - so I think the root cause here isn't specific to Solus or this system configuration.

It could just be misconfigured drivers (64 bit OpenGL - it's always initialized in Dota2 even if you are going to use the vulkan renderer).

I see in steam_system_information.txt that srsi failed to collect information for scout SLR (it worked for LD_* scout though), so even though 64 bit GL may be fine at host level, it could be broken in container. Somehow srsi worked for soldier SLR though, I would have expected it to fail as well if scout SLR doesn't pass..

[JacekJagosz]

This is the smoking gun that says libstdc++.so.6 was in LD_PRELOAD.

I spent a long time looking at Solus' Linux Steam Integration, and I made sure when native runtime is disabled nothing gets preloaded, checked env for running apps too. So I really can't see how could it happen on Solus side, doesn't Dota 2 on other distributions use libstdc++.so.6 as well?

@TTimo Could strace -e openat %command% as launch option tell something more about what libraries get loaded?

[TTimo]

@Horb 's steam_system_information.txt reports "LD_PRELOAD=/usr/$LIB/libxcb.so.1:/usr/$LIB/libX11.so.6:/usr/$LIB/libstdc++.so.6", in the "LD_* scout runtime" information - so maybe something isn't working as intended

[JacekJagosz]

Hmmm, sorry then. The fix I made just landed in Solus stable, @Horb when you have time could you please update, do sudo eopkg it linux-steam-integration --reinstall, make sure native runtime is disabled in Linux-Steam-Integration, and try again? If it is still broken I will need to search again why it gets preloaded.

[smcv]

doesn't Dota 2 on other distributions use libstdc++.so.6 as well?

Yes it does, but normally it goes through the container runtime's usual machinery for choosing whether to use the host or runtime version, similar to how we handle libgcc. Putting it in LD_PRELOAD bypasses that, in ways that are not helpful.

The intention is that libraries that the graphics drivers depend on (which usually includes libstdc++ and libgcc) come from the host or the container runtime, whichever one is newer, while libraries that aren't in the dependency tree of the graphics drivers (for example SDL and GTK) come from the container runtime only.

If an error message mentions /tmp/pressure-vessel-libs-*/i686/libstdc++.so.6, then it came from LD_PRELOAD (or possibly LD_AUDIT, but definitely don't do that). pressure-vessel only uses a directory matching that pattern for LD_PRELOAD and LD_AUDIT modules. I might change it to use a path more like /tmp/pressure-vessel-LD_PRELOAD-* or /run/pressure-vessel/LD_PRELOAD in a future version, to make it more obvious.

If an error message mentions /usr/lib/pressure-vessel/overrides/lib/*-linux-gnu/libstdc++.so.6 or /run/host/*/libstdc++.so.6 then it came from the host system.

If an error message from inside the container mentions /usr/lib/*-linux-gnu/libstdc++.so.6 then it came from the container runtime.

[Horb]

I've updated as @JacekJagosz suggests above. Dota 2 still crashes for me. My steam system information no longer reports a value for LD_PRELOAD. steam_system_information.txt slr-latest.log

SteamInternal_SetMinidumpSteamID:  Caching Steam ID:  76561197970349656 [API loaded yes]
SteamInternal_SetMinidumpSteamID:  Setting Steam ID:  76561197970349656
Setting breakpad minidump AppID = 373300
crash_20220601124336_2.dmp[16155]: Uploading dump (out-of-process)
/tmp/dumps/crash_20220601124336_2.dmp
/home/adam/.local/share/Steam/steamapps/common/dota 2 beta/game/dota.sh: line 109: 16141 Segmentation fault      (core dumped) ${STEAM_RUNTIME_PREFIX} ${GAME_DEBUGGER} "${GAMEROOT}"/${GAMEEXE} "$@"
12:43:36.850930: pressure-vessel-adverb[16076]: D: Child 16100 exited with wait status 35584
12:43:36.850985: pressure-vessel-adverb[16076]: I: Command exited with status 139
crash_20220601124336_2.dmp[16155]: Finished uploading minidump (out-of-process): success = yes
crash_20220601124336_2.dmp[16155]: response: CrashID=bp-fab5fdd2-ea73-4a1e-83cb-5b2a52220601
crash_20220601124336_2.dmp[16155]: file ''/tmp/dumps/crash_20220601124336_2.dmp'', upload yes: ''CrashID=bp-fab5fdd2-ea73-4a1e-83cb-5b2a52220601''
pid 16155 != 16154, skipping destruction (fork without exec?)
12:43:37.823175: pressure-vessel-adverb[16076]: D: Child 16155 exited with wait status 0
12:43:37.823250: pressure-vessel-adverb[16076]: D: No more child processes
12:43:37.823292: pressure-vessel-adverb[16076]: D: Exiting with status 139

Here's the .dmp file mentioned but renamed to a .txt file. crash_20220601124336_2.txt

[TTimo]

Compared to the previous set of logs, LD_PRELOAD is no longer set, and the out of process crash upload is working.

We are left with this startup crash caused by SDL_CreateWindow failing, maybe figuring why steam-system-runtime-info is failing for the scout SLR case will put us on the trail (CClientJobGatherRuntimeInformation: container read output failed in the log).

[TTimo]

@Horb you should be able to run the failing srsi diagnostic from the command line with a command like this:

.../SteamLinuxRuntime_soldier/run -- .../SteamLinuxRuntime/scout-on-soldier-entry-point-v2 -- steam-runtime-system-info

replace ... with the path to your steam library, looks like /home/adam/.local/share/Steam/steamapps/common it may give us better info to diagnose than the Steam client does atm

[Horb]

@TTimo, as requested; steam-runtime-system-info.txt

[TTimo]

The first surprise is that running the command at the CLI produced a full report, where the Steam client is failing. I'll have to look at this separately - it's likely a Steam client problem.

The report confirms that the GL drivers are not working in the container, either 32 or 64 bits.

64 bit first since that's what Dota 2 cares about:

Waffle error: 0x2 WAFFLE_ERROR_UNKNOWN: glXQueryExtensionsString failed it did find /run/host/usr/lib64/libGLX_mesa.so.0.0.0 from the host though, so not sure what's going on (incompatible ABI?)

The 32 bit driver fails also, with a bit more diagnostic this time:

libGL error: MESA-LOADER: failed to open radeonsi: /home/adam/.local/share/Steam/steamapps/common/SteamLinuxRuntime/var/steam-runtime/usr/lib/i386-linux-gnu/libstdc++.so.6: version GLIBCXX_3.4.29 not found (required by /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/dri/radeonsi_dri.so) (search paths /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/dri:/usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/dri, suffix _dri)

Both libstdc++ and radeonsi_dri come from the host, but it looks like they are trying to use the wrong/old libc (e.g. soldier's?)

Will have to defer to @smcv for further analysis (he's out for a few days).

[smcv]

Both libstdc++ and radeonsi_dri come from the host, but it looks like they are trying to use the wrong/old libc (e.g. soldier's?)

Not quite - the error libstdc++.so.6: version GLIBCXX_3.4.29 not found means that the (32-bit) radeonsi driver is trying to use the wrong/old libstdc++.

For context, since this gets pretty complicated: the environment that Dota 2 is meant to run in is a hybrid of Steam Runtime 1 'scout' (the environment it was compiled in, based on Ubuntu 12.04 from 2012), the Steam Runtime 2 'soldier' container runtime (based on Debian 10 from 2019), and the host system (in this case Solus).

For SONAMEs in the dependency stack of the graphics drivers, like libstdc++, the intention is to use the host system's copy, or soldier's copy, whichever is a newer version (with the host system preferred if the versions look the same). If neither the host nor soldier has a particular SONAME, then scout's copy is used as a fallback (but by definition this shouldn't happen for dependencies of the graphics drivers, because if the host system doesn't have those then something has gone very wrong).

For SONAMEs not in the dependency stack of the graphics drivers, like SDL, the intention is to use soldier's copy. If soldier doesn't have a particular SONAME (like the old libtiff.so.4 in scout, which has been superseded by libtiff.so.5 in soldier), then scout's copy is used as a fallback. As an exception to this, a small number of libraries that have had awkward ABI transitions in the past (basically libcurl) get "pinned" so that the versions from scout are preferred even though they're old.

From the "overrides" section of the s-r-s-i info dump, we can see that the pressure-vessel container tool has selected the host system's libstdc++ as being newer than soldier's libstdc++, for both the i386-linux-gnu (32-bit) and x86_64-linux-gnu (64-bit) ABIs. Solus is a rolling-release distro, so this seems likely to be correct: its libstdc++ is probably newer than the one in soldier.

However, what is not working as intended is that when the diagnostic tools try to load the Radeon drivers, they load scout's libstdc++, which is from approximately 2013. As you might expect, that works poorly.

I think this is a problem with the LD_LIBRARY_PATH runtime environment, perhaps caused by a bad interaction between run.sh, the pressure-vessel container, and Solus's ldconfig executable. We can see that it has set up this LD_LIBRARY_PATH (linebreaks added for clarity):

/home/adam/.local/share/Steam/steamapps/common/SteamLinuxRuntime/var/steam-runtime/pinned_libs_32:
/home/adam/.local/share/Steam/steamapps/common/SteamLinuxRuntime/var/steam-runtime/pinned_libs_64:
/usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/aliases:
/usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/aliases:
/usr/lib:
/usr/lib64:
/usr/lib32:
/home/adam/.local/share/Steam/steamapps/common/SteamLinuxRuntime/var/steam-runtime/lib/i386-linux-gnu:
/home/adam/.local/share/Steam/steamapps/common/SteamLinuxRuntime/var/steam-runtime/usr/lib/i386-linux-gnu:
/home/adam/.local/share/Steam/steamapps/common/SteamLinuxRuntime/var/steam-runtime/lib/x86_64-linux-gnu:
/home/adam/.local/share/Steam/steamapps/common/SteamLinuxRuntime/var/steam-runtime/usr/lib/x86_64-linux-gnu:
/home/adam/.local/share/Steam/steamapps/common/SteamLinuxRuntime/var/steam-runtime/lib:
/home/adam/.local/share/Steam/steamapps/common/SteamLinuxRuntime/var/steam-runtime/usr/lib

I would have expected to see two more entries just above /usr/lib:

• /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu
• /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu

These are meant to be added as a result of run.sh parsing the output of ldconfig -XNv, which has been set up by the pressure-vessel container tool rewriting /etc/ld.so.conf to be a symlink to /run/pressure-vessel/ldso/ld.so.conf, which starts with those two paths. Clearly something has gone wrong somewhere and those paths have got lost.

[smcv]

Aha, I've got it. Solus patches its ldconfig to use a non-interoperable path to ld.so.conf:

https://dev.getsol.us/source/glibc/browse/master/files/0003-elf-ldconfig-Use-a-stateless-ld.so.conf.patch

pressure-vessel needs to modify ld.so.conf inside the container, but we currently only apply our modification to the interoperable path, and not to the Solus-specific path. We'll need to create a symlink at the Solus-specific path pointing to the interoperable path, or something like that. This might not solve the entire problem, but it'll certainly help.

We already do the equivalent for a couple of different distro-specific ld.so.cache files (ClearLinux and Exherbo), but Solus is the first distro-specific ld.so.conf file that I've seen.

[smcv]

@Horb, please could you try replacing ~/.steam/root/ubuntu12_32/steam-runtime/run.sh with this one, which has the change from ValveSoftware/steam-runtime#509?

I'm not sure whether this is the best place to fix this issue in the long term or just a workaround, but it should at least be enough to see whether this is the root cause for all your problems with Dota 2 or whether there's something else.

[smcv]

An interesting quirk here is that because this is a bad interaction between Solus, the container runtime and the LD_LIBRARY_PATH runtime, it will generally only affect native Linux games that were built for scout. Normally, when people report bugs involving the container runtime, the first place we see it reported is for Proton versions that use the container runtime (5.13 or later) - but because Proton uses a "pure" soldier environment without the legacy scout libraries, it's unaffected by this particular problem.

[smcv]

@JacekJagosz, if you're a Solus user or developer and can reproduce this or a similar failure mode for Dota 2 (it's free, although quite a large download), please could you also try what I said in https://github.com/ValveSoftware/steam-runtime/issues/510?

[Horb]

@smcv thank you. The shock and joy I felt when Dota 2 launched from Steam for the first time in I don't know how long :grinning:

After replacing my run.sh as instructed the issue is resolved.

[smcv]

The replacement run.sh is just a workaround, but now that I know it works for you, I'll look into what the best place for a proper fix is (there are a couple of options).

@kisak-valve, do you want to move this to ValveSoftware/steam-runtime? It was reported as a Dota 2 bug, but it looks like the real root cause is Solus and the Steam Runtime not interoperating, with the Dota 2 crash just being a symptom of that.

It looks like the LD_PRELOAD thing might also not have been the true root cause, so perhaps fails to launch on Solus due to ld.so.conf path would be a better title.

[smcv]

Please could a Solus user, perhaps @Horb or @JacekJagosz, try out what is hopefully a more permanent solution to this?

Steps:

1. Undo the previous workaround by replacing ~/.steam/root/ubuntu12_32/steam-runtime/run.sh with the production version, which you can unpack from ~/.steam/root/ubuntu12_32/steam-runtime.tar.xz or get from https://github.com/ValveSoftware/steam-runtime/blob/master/templates/run.sh
2. Try to run Dota 2. Hopefully the bug will be back (Dota should fail to launch).
3. Replace SteamLinuxRuntime_soldier/pressure-vessel/ with the result of unpacking this prerelease build: https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/jobs/82850/artifacts/raw/_build/production/pressure-vessel-bin.tar.gz (from this merge request)
4. Try to run Dota again. Hopefully the bug will be fixed (Dota should launch successfully).

[Horb]

I restored my run.sh and reproduced the issue.

I then replaced my pressure-vessel directory at .local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier with the one provided above and the issue was resolved.

[JacekJagosz]

I even verified Dota 2 now works just fine even with Native runtime enabled, and the Intercept Library enabled in our Linux-Steam-Integration. Thank you so much for all the investigative work!

[smcv]

I then replaced my pressure-vessel directory at .local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier with the one provided above and the issue was resolved.

Great, we should be able to include that change in the next soldier and sniper beta releases. I'll update this issue when that has happened.

now works just fine even with Native runtime enabled

I'm sure you know this already, but if this is the same as Arch's "native runtime" (disabling the LD_LIBRARY_PATH runtime and using host libraries exclusively), then this is unsupportable. Steam will continue to make changes and additions to its LD_LIBRARY_PATH runtime as they become necessary, and if OS distributors' "native runtimes" don't keep up with that, then Steam and games will not work.

If it brings you some sort of benefit, I would prefer it if we can find a way to get that benefit without it. The traditional LD_LIBRARY_PATH runtime already prefers to use host libraries in almost all cases, unless the library in the runtime is strictly newer (typically meaning libraries that we actively backport, like SDL and Vulkan-Loader) in which case using the newer version is required. The exceptions at the moment are libcurl, because of some historical ABI divergence that we're stuck with now, and a couple of 32-bit D-Bus-related libraries.

Using a "native runtime" will have little or no effect on the container runtime, which works differently anyway.

[smcv]

pressure-vessel needs to modify ld.so.conf inside the container, but we currently only apply our modification to the interoperable path, and not to the Solus-specific path.

Fixed in today's beta releases (SteamLinuxRuntime_soldier and SteamLinuxRuntime_sniper client_beta branch, VERSIONS.txt will say pressure-vessel 0.20220624.0 or later).

The default branch is not yet fixed; the beta will probably be copied to the default branch in a few weeks.

[smcv]

Fixed in today's beta releases (SteamLinuxRuntime_soldier and SteamLinuxRuntime_sniper client_beta branch, VERSIONS.txt will say pressure-vessel 0.20220624.0 or later).

The default branch is not yet fixed; the beta will probably be copied to the default branch in a few weeks.

This change has now been promoted to the default branch.

[kisak-valve]

Closing per the last comment.