search

ValveSoftware / steam-for-linux

Issue tracking for the Steam for Linux beta client
4.22k stars 174 forks source link

No Steam overlay in 32-bit games if Proton/soldier on filesystem with 64-bit inode numbers #9225

Open priand1 opened 1 year ago

priand1 commented 1 year ago

Your system information

System Information

Please describe your issue in as much detail as possible:

Expected result

The steam overlay is showing with 32bit games when pressing the hotkey.

Actual result

The steam overlay does not show on any 32bit game. It does not matter if it is a native game (e.g. Borderlands 2) or a 32bit windows game started using proton/slr. Currently the steam overlay is only working for native/windows 64bit games.

The following log was taken using the game 'Floating Point (302380)', using pv 20230216 and the launch parameters STEAM_LINUX_RUNTIME_LOG=1 and STEAM_LINUX_RUNTIME_VERBOSE=1:

SLR log 32bit no steam overlay

This is the same log I used in a different issue. If this isn't enough, please let me know.

Steps for reproducing this issue:

  1. Start any 32bit game, no matter if it is native or using proton/slr.
  2. Press the hotkey to open the steam overlay.
  3. The overlay does not appear.
RyuzakiKK commented 1 year ago

At first glance I can't spot anything out of the ordinary from the log.

There is the libMangoApp.json manifest that points to a missing /usr/$LIB/mangohud/libMangoApp.so, but that shouldn't matter.

Is the overlay broken even if you have MangoHud disabled?

smcv commented 1 year ago

It might be helpful to reduce this down to the simplest possible scenario for a 32-bit game, which is: a native Linux game, with a 32-bit executable, no third-party overlays (so don't enable MangoHud), no container runtime, and no Proton.

To get that, please try running Steam from a terminal (Konsole or similar), without MangoHud; then go into the Properties of Floating Point, and in "Compatibility", turn off "Force the use of...". Steam should download the Linux version of it. (I know that's the opposite of what I asked you to do earlier, but that was when we thought this was a container runtime problem.)

Then run Floating Point. If you get a GTK window titled "Floating Point Configuration", click OK to start the game. Press Shift+Tab to try to bring up the overlay. If successful, press Shift+Tab to close the overlay again. Press Alt+F4, or press Escape and click on Quit, to leave the game.

Then Alt+Tab to the terminal, and see what output Steam has produced (there's no log file when you're not using the container runtime). It should look something like this:

/bin/sh\0-c\0/home/you/.../reaper SteamLaunch AppID=302380 ...
Game process added : AppID 302380 "..."
...
Game process removed: AppDI 302380 "..."
Uploaded AppInterfaceStats to Steam
smcv commented 1 year ago

Looking at your log, I can see that we are finding the Steam overlay:

14:52:21.801828: pressure-vessel-wrap[6913]: D: Adjusting LD_AUDIT/LD_PRELOAD modules...
14:52:21.801838: pressure-vessel-wrap[6913]: D: /home/atze/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so -> unmodified
14:52:21.801850: pressure-vessel-wrap[6913]: D: Skipping exposing "/home/atze/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so" because it is located under the Steam client install path that we bind by default
14:52:21.801860: pressure-vessel-wrap[6913]: D: /home/atze/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so -> unmodified
14:52:21.801872: pressure-vessel-wrap[6913]: D: Skipping exposing "/home/atze/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so" because it is located under the Steam client install path that we bind by default
14:52:21.801883: pressure-vessel-wrap[6913]: D: Making Steam environment variables available if required...
14:52:21.801898: pressure-vessel-wrap[6913]: I: Bind-mounting STEAM_COMPAT_CLIENT_INSTALL_PATH="/home/atze/.local/share/Steam" from the current env as STEAM_COMPAT_CLIENT_INSTALL_PATH="/home/atze/.local/share/Steam" in the host

and later:

14:52:21.812641: pressure-vessel-wrap[6913]: D:     '--ld-preload=/home/atze/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so'
14:52:21.812651: pressure-vessel-wrap[6913]: D:     '--ld-preload=/home/atze/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so'

And then inside the container, we can successfully find and open the overlay modules:

14:52:21.846096: pressure-vessel-adverb[7024]: D: Module /home/atze/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so is for i386-linux-gnu
14:52:21.846122: pressure-vessel-adverb[7024]: D: created symlink /tmp/pressure-vessel-libs-LLJU01/i686/gameoverlayrenderer.so -> /home/atze/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
14:52:21.846136: pressure-vessel-adverb[7024]: D: Module /home/atze/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so is for x86_64-linux-gnu
14:52:21.846152: pressure-vessel-adverb[7024]: D: created symlink /tmp/pressure-vessel-libs-LLJU01/x86_64/gameoverlayrenderer.so -> /home/atze/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so

and we pass this environment to the game:

14:52:21.873504: pressure-vessel-adverb[7024]: N:   'LD_PRELOAD=/tmp/pressure-vessel-libs-LLJU01/${PLATFORM}/gameoverlayrenderer.so'

All of that looks normal; I don't see any obvious problems.

smcv commented 1 year ago

One possible cause for 32-bit-specific weirdness, although it seems quite unlikely, might be:

Are any of the executables involved in launching a 32-bit process setuid or setgid? What I mean by that is: if you do

ls -al --dereference /lib/ld-linux.so.2

the expected result starts with something like -rwxr-xr-x, but if you see a s or S instead of the x, then that would cause the LD_PRELOAD (and also the Vulkan modules on https://github.com/ValveSoftware/steam-runtime/issues/567) to be ignored.

Or if not ld-linux.so.2, then similar for any of the executables involved in pressure-vessel, Proton, or the game?

Or if not setuid or setgid, perhaps you have a LSM (Linux security module) like AppArmor or SELinux which might have a similar effect?

priand1 commented 1 year ago

I'll try to answer all questions in one post:

  1. This is what I get when I enter " ls -al --dereference /lib/ld-linux.so.2" -rwxr-xr-x 1 root root 226660 Feb 9 16:45 /lib/ld-linux.so.2

I had AppArmor running. I stopped the service and disabled it for now. After that, no changes for me which means no steam overlay for 32bit games. I don't use SELinux.

  1. @RyuzakiKK : Is the overlay broken even if you have MangoHud disabled? A: Yes, on all 32bit games. Even if Mangohud is disabled, no matter if the game is linux native or a windows game.

  2. For whatever reason I cannot use 'Floating Point' natively. It crashes immediately when I press the play button. It does not even run with the Steam Runtime enabled. Same behaviour, crashes immediately.

So I used Borderlands 2 without MangoHud and here is the console output:

Borderlands 2 (49520) linux native w/o MangoHud

The result: No steam overlay.

As a side note: I run Borderlands 2 natively only, not with proton, and this game is one of the few 32bit games - all native linux games - that does show Mangohud when I add 'MANGOHUD_DLSYM=1 mangohud' to the launch parameters.

Just in case you might want me to do it, as Floating Point crashes natively I started it with proton/soldier without MangoHud and this is the console output:

Floating Point w proton/soldier w/o MangoHud

and here is the accompanying log file:

Logfile Floating Point w proton/soldier w/o MangoHud

The result: No steam overlay.

smcv commented 1 year ago

For whatever reason I cannot use 'Floating Point' natively. It crashes immediately when I press the play button

That's probably useful information! It's a relatively simple game (when compared with something like Proton, at least...) so I would usually expect it to work on "most" Linux systems.

Please can you run Steam from a terminal, try launching Floating Point with no compatibility tools, and get the console output from that?

smcv commented 1 year ago

I see you are using some workarounds/tweaks/changes with Borderlands 2, presumably by editing its Launch Options:

/bin/sh\0-c\0LD_PRELOAD='$HOME/.steam/root/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/libopenal.so.1' SSL_CERT_DIR=/etc/ssl/certs gamemoderun /home/atze/.local/share/Steam/ubuntu12_32/reaper SteamLaunch AppId=49520 -- /home/atze/.local/share/Steam/ubuntu12_32/steam-launch-wrapper -- '/home/atze/inode32/SteamLibrary/steamapps/common/Borderlands 2/./Borderlands2' --nomoviestartup\0

This would explain why you don't get any Steam Overlay, for this game at least. Setting LD_PRELOAD to any value overwrites its previous value, and its previous value is exactly the Steam Overlay.

I think setting LD_PRELOAD='$HOME/.steam/root/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/libopenal.so.1' is also not going to help to work around anything, because you used single quotes, and that means the $HOME variable is not expanded, so the dynamic linker is trying to look in a subdirectory like SteamLibrary/steamapps/common/Borderlands 2/$HOME, which is almost certainly not what you meant.

Please try removing those changes (presumably workarounds?) from its Launch Options, and see whether that gives you a Steam Overlay in this game.

Or, you could try a different 32-bit native Linux game. 32-bit games that I often use for testing include Team Fortress 2 (which is free), Life Is Strange episode 1 (which is also free) and Portal 2 (which isn't, but you might already have it?).

priand1 commented 1 year ago

Thanks a lot! I have been using the LD_PRELOAD= workaround for a long time now, otherwise Borderlands 2 had crashed in the past. I got it from the Arch Wiki. After removing it I have a working steam overlay in Borderlands 2 again even if I run BL2 with MangoHud. I had the same workaround for Borderlands: The Pre Sequel and after removing it the steam overlay was working again. Thanks again!

As for Floating Point, here is the console output when run natively:

Floating Point linux native console output

I am giving Team Fortress 2 and Life Is Strange Episode 1 a try. I just started downloading them and as soon as they have finished I'll be back.

smcv commented 1 year ago

As for Floating Point, here is the console output when run natively:

This says There is no data folder which looks suspicious. Has the Floating Point_Data folder perhaps gone missing while you were swapping between versions? If it has, Properties -> Local Files -> "Verify integrity of game files..." should bring it back.

priand1 commented 1 year ago

No, it's present. With underscore between Point and Data. I also verified the game files. It still crashes.

~/games/SteamLibrary/steamapps/common/Floating Point/Floating Point_Data>

priand1 commented 1 year ago

I have some strange things happening here.

Life Is Strange is also crashing. I have the follwing in my console:

/home/atze/games/SteamLibrary/steamapps/common/Life Is Strange/bin/LifeIsStrange: error while loading shared libraries: libCoreFoundation.so.476: cannot open shared object file: No such file or directory

This folder does not exist and the file in question is in /home/atze/games/SteamLibrary/steamapps/common/Life Is Strange/lib/x86_64/

Team Fortress 2 also isn't starting and gives me Out of memory or address space. Texture quality setting may be too high. in the console and as a pop-up notification. Game files have been verified for both games.

My steam library is on an xfs filesystem and I have no clue what is going on. Will reboot now, then be back and report later.

priand1 commented 1 year ago

Here is what was going on: I have two internal HDDs, both using the xfs filesystem. One is 16TB and 64bit xfs, one is 2TB and 32bit xfs. Years ago, I had to move Borderlands 2 and Borderlands: TPS to the 2TB disk with 32bit xfs because they would not start from a 64bit xfs filesystem. Windows 32bit games never had that problem so I left them on the 16TB disk with 64bit xfs.

I forgot about that and installed Floating Point, Team Fortress and Life Is Strange on the 16TB disk with 64bit xfs.

After moving these three games to the 2TB disk two of them started: Team Fortress 2 and Floating Point. Both have a steam overlay and both show mangohud.

Life Is Strange on the other hand does still not start because of the /home/atze/games/SteamLibrary/steamapps/common/Life Is Strange/bin/LifeIsStrange: error while loading shared libraries: libCoreFoundation.so.476: cannot open shared object file: No such file or directory error. And by the way, I erred again: 'LifeIsStrange' from the error is a binary and not a directory as I assumed, complaining about not finding the desired library.

Up to this point I can say that this problem is partially fixed: 32bit native linux games have a steam overlay and show mangohud when installed on a 32bit xfs filesystem.

32bit windows games still do not have a steam overlay. I moved Sniper Ghost Warrior 2 to the 2TB disk and switched Floating Point to use proton/soldier and tried both. Both do not have a steam overlay.

I am clueless right now how to proceed from here.

smcv commented 1 year ago

I have two internal HDDs, both using the xfs filesystem. One is 16TB and 64bit xfs, one is 2TB and 32bit xfs.

By 64-bit and 32-bit, I assume you mean 64- or 32-bit inode numbers?

Yes, 64-bit inode numbers can cause problems for 32-bit executables. We've already fixed several parts of the Steam Runtime to use "large file support" interfaces (which have the side-effect of also fixing the ability to access files with large inode numbers), but this is a problem that could occur at any layer of the stack, including the Steam Runtime, Proton, and things not under Valve's control (like your OS libraries and third-party games), and it is not always possible to fix without causing incompatibilities. Floating Point is old and basically unmaintained, so it wouldn't surprise me if it's using the old interfaces that can't cope with large inode numbers.

On the games that you have moved to a filesystem with small inode numbers, I don't know why the overlay isn't appearing. Have you tried also moving "Steam Linux Runtime - soldier", and whatever version of Proton you're using?

priand1 commented 1 year ago

By 64-bit and 32-bit, I assume you mean 64- or 32-bit inode numbers?

Yes, this is what I meant.

On the games that you have moved to a filesystem with small inode numbers, I don't know why the overlay isn't appearing. Have you tried also moving "Steam Linux Runtime - soldier", and whatever version of Proton you're using?

I just did that after reading your comment by moving slr soldier and proton to the 32bit inodes drive and now also 32bit windows games have a steam overlay. The games I tried were Floating Point (as win32), Sniper Ghost Warrior 2 and a non-steam 32bit windows game.

It doesn't even matter if these 32bit windows games themselves are on a 32bit indodes xfs or not, they show a working steam overlay even when they reside on a 64bit inodes xfs as long as slr soldier and proton reside on a 32bit inodes xfs filesystem or on a btrfs partition, please see below.

My "/" and "/home" are on a 500GB nvme sporting btrfs. I can move slr soldier and proton to /home/atze/.steam/steam/steamapps/common/ on this filesystem and the three games I tested are still showing a steam overlay.

As for now the situation for me is as follows, only observing, not drawing conclusions:

Even though the above, concerning the locations of games/slr/proton depending on the bittiness of games, seems more like a workaround it is helping me getting steam overlay and even mangohud to work.

As long as you don't have any objections I will close No MangoHud showing on 32bit windows games when started with linux-runtime soldier #567 as solved.

Concerning this issue report I am not sure if it should be closed as solved. I will leave that to you to decide. If you intend to keep it open and need more infos and logs I am glad to help.

Thank you, sir!

smcv commented 1 year ago

32bit windows games show a steam overlay as long as slr soldier and proton reside on a 32bit inodes xfs partition or on a btrfs partition, no matter where these games themselves reside

For completeness, the specific filesystem in use probably doesn't matter here: what matters is whether the inode number (of the specific files that the game is opening, even!) is too large.

The problem comes when a 32-bit process wants to look at the metadata of a file, and the process is using old interfaces (older than "large file support"), and the file it wants to look at happens to have been allocated an inode number that is 2**32 or more, which won't fit in the space allowed.

We probably need to look at whether the Steam Runtime's 32-bit libraries were compiled with large file support or not. If they weren't, we can try to recompile them with large file support and that might solve this. Or, the developers of Proton might need to check whether their 32-bit code was compiled with large file support, or bits of Steam itself might have to be compiled with large file support - it's not obvious. I think we should leave this issue open while we look into which layer is the one with the problem here.

It would be useful if you could try putting Proton on one filesystem, and soldier on the other: that would narrow down which one it is that's important here. So:

smcv commented 1 year ago

Also it would be useful if you or @kisak-valve could retitle this to something like "No Steam overlay in 32-bit games if Proton/soldier on filesystem with 64-bit inode numbers" now that we understand more about why this is happening, so we don't get confused by follow-ups from people who don't get the Steam overlay for some other reason.

priand1 commented 1 year ago

It would be useful if you could try putting Proton on one filesystem, and soldier on the other: that would narrow down which one it is that's important here. So:

 * Proton on fs with 64-bit inode numbers, soldier on fs with 64-bit inode numbers: bad

 * Proton on fs with 64-bit inode numbers, soldier on fs with 32-bit inode numbers: good

 * Proton on fs with 32-bit inode numbers, soldier on fs with 64-bit inode numbers: bad

 * Proton on fs with 32-bit inode numbers, soldier on fs with 32-bit inode numbers: good

Looks like a working steam overlay/mangohud for 32bit windows games depends on the location of slr soldier only.

smcv commented 1 year ago

Thanks, that narrows it down: something in the stack must be looking at a file or directory from soldier using old 32-bit APIs. So far I'm not seeing any particularly obvious candidates, but at least now we know approximately where to look...

YellowOnion commented 1 year ago

I'm running bcachefs & NixOS, and some of this looks familiar to me, never seen the HUD in 32bit games, and what's worse is after 30mins, games lag profusely due to micro stutter from input devices like mouse, and apparently it can be remedied by disabling the overlays.

YellowOnion commented 1 year ago

@smcv I noticed HL1 crashes on my desktop with bcachefs (64bit inodes), but not on my laptop (xfs), both nixos and similar setups, perhaps related / allows us to narrow it down.

YellowOnion commented 1 year ago

@smcv Is there anything I can help with for debugging this issue? It's SO annoying, Portal can't see any maps, or saves, you have to manually type them in to console, and the stutter bug is just infuriating if you forget to set up the hack to disable the overlay, because steam still injects the overlay even when it's toggled off.

something in the stack must be looking at a file or directory from soldier using old 32-bit APIs

Could we replace the API with a stub that throws an error / stacktrace that lets us report the location to you?