steam-runtime

steam-runtime copied to clipboard

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.

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?

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

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

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

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

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: @.***>

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.

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.

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

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.

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.

@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?

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.

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...

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

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.

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.

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

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.

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.

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

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''

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 :(

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.

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 '']

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

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

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..

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?

@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

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.