-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dota 2 fails to launch on Solus due to ld.so.conf path #510
Comments
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 |
I've been toggling options in that utility all day 🙃 It's the same result with |
This is a blind guess, but can you verify the integrity of |
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
<#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:
This will give us more information about how the libraries on your system compare with the libraries in the container. Additionally adding
This indicates that the container tool is correctly loading a newer |
Recreated this reply because my system information was incomplete. I ran;
System Information: https://gist.github.com/Horb/5754c7f9a4001e3235f4bc2fd8a9ea45 |
Looks like Steam was run with:
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 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? |
The problem is that when people use something like We have a heuristic that can filter out However, looking more carefully at the latest log from @Horb, it seems there are two separate problems here:
@Horb, perhaps you could try running Dota 2 with these launch options?
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.
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 |
Launched steam with; Steam System Information: https://gist.github.com/Horb/3895c35611743550d0caf3cb40cb153b |
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:
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 |
As I said in #510, I think the |
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 I think the id is CrashID=bp-f00ba326-3fd8-4b30-bd5e-a247b2220511 based on this snippet from the above log;
|
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 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 I still see in the SLR logs indications that
|
This is the smoking gun that says |
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 |
Compared to the previous set of logs, We are left with this startup crash caused by |
@Horb you should be able to run the failing srsi diagnostic from the command line with a command like this:
replace |
@TTimo, as requested; |
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:
The 32 bit driver fails also, with a bit more diagnostic this time:
Both Will have to defer to @smcv for further analysis (he's out for a few days). |
Not quite - the error 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 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
I would have expected to see two more entries just above
These are meant to be added as a result of |
Aha, I've got it. Solus patches its pressure-vessel needs to modify We already do the equivalent for a couple of different distro-specific |
@Horb, please could you try replacing 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. |
An interesting quirk here is that because this is a bad interaction between Solus, the container runtime and the |
@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 #510? |
@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 😀 After replacing my run.sh as instructed the issue is resolved. |
The replacement @kisak-valve, do you want to move this to It looks like the |
Please could a Solus user, perhaps @Horb or @JacekJagosz, try out what is hopefully a more permanent solution to this? Steps:
|
I restored my run.sh and reproduced the issue. I then replaced my pressure-vessel directory at |
I even verified Dota 2 now works just fine even with Native runtime enabled, and the Intercept Library enabled in our Linux-Steam-Integration. |
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.
I'm sure you know this already, but if this is the same as Arch's "native runtime" (disabling the 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 Using a "native runtime" will have little or no effect on the container runtime, which works differently anyway. |
Fixed in today's beta releases (SteamLinuxRuntime_soldier and SteamLinuxRuntime_sniper 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. |
Closing per the last comment. |
Unfortunately this update had to be rolled back due to some unrelated regressions (#518, etc.) so we are back to only the |
We fixed #518, etc., so this fix made it to the default branch a while later (early August 2022, I think). Please re-test the default branch on Solus: this should now be fixed. |
Closing per the last comment. |
Your system information
Steam
->Help
->System Information
) in a gist: https://gist.github.com/Horb/847d6691ad42f0c855d223e48ab32cedPlease 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:
The text was updated successfully, but these errors were encountered: