Steam (Proton) games will not launch under specific circumstances

[b02860de585071a2]

Describe the bug
Steam games (run through Proton) no longer launch if the MANGOHUD=1 environment variable is set. Games will attempt to start, but show "running..." indefinitely in Steam, and will never actually launch.

List relevant hardware/software information

• Linux Distribution: Arch (6.3.1-arch1-1)
• MangoHud version: 0.6.9.1-1
• GPU: Nvidia RTX 4080

To Reproduce
Steps to reproduce the behavior:

1. Declare MANGOHUD=1 as an environment variable (ie export MANGOHUD=1 in bash)
2. Open launch options of a game on Steam
3. Ensure that the mangohud %command% option is NOT set
4. Attempt to launch the game

To "fix":

1. Ensure that the previous MANGOHUD=1 variable is NOT set
2. Add mangohud %command% to game launch options
3. Launch game as normal

Expected behavior
Proton games should launch, as they have up to this point.

Additional context
This only became an issue approximately 48 hours ago, with a large Arch update. I have dug through Proton and Steam logs, and found no meaningful errors.

I believe I have traced the issue to gcc/gcc-libs 13.1.1-1 (and its dependencies: gcc-multilib, binutils, etc), as rolling back upgrades to these packages resolves the problem. However, this may only be a symptom of something deeper - but I am not qualified to dig further.

Here is a Proton log from an example game (Half-Life, installed on a clean prefix and run with Proton Experimental [rather than the native Linux version]). As you can see, Proton doesn't seem to flag anything abnormal until I forcibly terminate the application.

[flightlessmango]

Try recompiling mangohud

[b02860de585071a2]

I have tried a few different things, to ensure it's not some incompatibility on my end:

• Clean reinstall from the AUR
• Switching from mangohud (0.6.9.1-1) to mangohud-git (0.6.8.r145.g020e848-1) in the AUR
• Doing a completely clean build from source (ie deleting all files created by MangoHud, cloning the git repo, and compiling manually)

None of these have resolved the issue.

[Bobbydigital420]

Also having this issue. Running Arch on the same kernel and mangohud versions but on a RTX 3070. Games run fine using the mangohud command in the steam prefix but using the environment variable MANGOHUD=1 either causes the game to show "running..." indefinitely in Steam or just exit.

After testing out a few games it seems to only be on certain games that it doesn't work. The Last of Us. Days Gone and Dying Light 2 won't launch with the environment variable, was able to get Horizon Zero Dawn and Control working with it.

Tried deleting the game prefixes for the non working games and recompiling MangoHud plus using a clean config file for it but had no success. If you need any logs just let me know and I will post them.

[kodatarule]

Additional context This only became an issue approximately 48 hours ago, with a large Arch update. I have dug through Proton and Steam logs, and found no meaningful errors.

I believe I have traced the issue to gcc/gcc-libs 13.1.1-1 (and its dependencies: gcc-multilib, binutils, etc), as rolling back upgrades to these packages resolves the problem. However, this may only be a symptom of something deeper - but I am not qualified to dig further.

Here is a Proton log from an example game (Half-Life, installed on a clean prefix and run with Proton Experimental [rather than the native Linux version]). As you can see, Proton doesn't seem to flag anything abnormal until I forcibly terminate the application.

I am also affected by this, EndeavourOS, but also on a brand new Arch install. Both mangohud-git and lib32-mangohud-git packages installed and again seems linked to gcc/gcc-libs(as for example mangohud/lib32-mangohud/mangohud-common fail to build with gcc 13).

Steam also hangs upon exit if mangohud is enabled globally for me...

In addition gcc/gcc-libs/libs32-gcc-libs 13 seems to cause a lot of issues(namely I can't compile with it nvidia-utils-nvlax, plasma5-wallpapers-engine-wallpaper, libstrangle-git)...

Downgrading the gcc to 12 also isn't a solution as other things break and require further downgrading...

[xpander69]

This seems to be an issue with proton 8 only. I have proton-experimental with branch set to 7, instead of 8 and it works without issues with mangohud globally enabled. (Arch Linux, fully updated)
probably some more investigation needed on this ofc.

[b02860de585071a2]

seems linked to gcc/gcc-libs(as for example mangohud/lib32-mangohud/mangohud-common fail to build with gcc 13).

Steam also hangs upon exit if mangohud is enabled globally for me...

Exact same behavior for me, on both counts. Building mangohud or mangohud-common will throw the same errors, and Steam will not terminate no matter what I throw at it.

Terminal output when attempting to build from AUR

This is the relevant part of the failure:

In file included from ../MangoHud/tests/../src/amdgpu.h:8,
                 from ../MangoHud/tests/test_amdgpu.cpp:9:
../MangoHud/tests/../src/overlay_params.h:229:21: error: ‘uint32_t’ is not a member of ‘std’; did you mean ‘wint_t’?
  229 |    std::vector<std::uint32_t> fps_limit;
      |                     ^~~~~~~~
      |                     wint_t
../MangoHud/tests/../src/overlay_params.h:229:21: error: ‘uint32_t’ is not a member of ‘std’; did you mean ‘wint_t’?
  229 |    std::vector<std::uint32_t> fps_limit;
      |                     ^~~~~~~~
      |                     wint_t
../MangoHud/tests/../src/overlay_params.h:229:29: error: template argument 1 is invalid
  229 |    std::vector<std::uint32_t> fps_limit;
      |                             ^
../MangoHud/tests/../src/overlay_params.h:229:29: error: template argument 2 is invalid
[39/73] Compiling C++ object src/libMangoHud.a.p/overlay_params.cpp.o
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in build().

The build throws multiple errors, all of which come from usage of uint32_t.

[Bobbydigital420]

seems linked to gcc/gcc-libs(as for example mangohud/lib32-mangohud/mangohud-common fail to build with gcc 13).
Steam also hangs upon exit if mangohud is enabled globally for me...

Exact same behavior for me, on both counts. Building mangohud or mangohud-common will throw the same errors, and Steam will not terminate no matter what I throw at it.

Terminal output when attempting to build from AUR

This is the relevant part of the failure:

In file included from ../MangoHud/tests/../src/amdgpu.h:8,
                 from ../MangoHud/tests/test_amdgpu.cpp:9:
../MangoHud/tests/../src/overlay_params.h:229:21: error: ‘uint32_t’ is not a member of ‘std’; did you mean ‘wint_t’?
  229 |    std::vector<std::uint32_t> fps_limit;
      |                     ^~~~~~~~
      |                     wint_t
../MangoHud/tests/../src/overlay_params.h:229:21: error: ‘uint32_t’ is not a member of ‘std’; did you mean ‘wint_t’?
  229 |    std::vector<std::uint32_t> fps_limit;
      |                     ^~~~~~~~
      |                     wint_t
../MangoHud/tests/../src/overlay_params.h:229:29: error: template argument 1 is invalid
  229 |    std::vector<std::uint32_t> fps_limit;
      |                             ^
../MangoHud/tests/../src/overlay_params.h:229:29: error: template argument 2 is invalid
[39/73] Compiling C++ object src/libMangoHud.a.p/overlay_params.cpp.o
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in build().

The build throws multiple errors, all of which come from usage of uint32_t.

It seems with GCC13 that

#include <cstdint>

needs to be included for 'uint32_t'
Can't test myself right now as I'm working at the moment.

[Bobbydigital420]

https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes

Some C++ Standard Library headers have been changed to no longer include other headers that were being used internally by the library. As such, C++ programs that used standard library components without including the right headers will no longer compile.

The following headers are used less widely in libstdc++ and may need to be included explicitly when compiling with GCC 13:

<string> (for std::string, std::to_string, std::stoi etc.)
<system_error> (for std::error_code, std::error_category, std::system_error).
<cstdint> (for std::int8_t, std::int32_t etc.)
<cstdio> (for std::printf, std::fopen etc.)
<cstdlib> (for std::strtol, std::malloc etc.)

[Bitwolfies]

To add to this, proton 7 also broke for me with mangohud's global enable, hope a fix can be pushed.

[toboggan7]

Same here - both proton 7 and 8 don't work, and it screws with d3ddriverquery.exe, affecting the base Steam client and not allowing it to close properly.

[flightlessmango]

I haven't been able to repro this. Is this isolated to nvidia GPUs possibly?

[b02860de585071a2]

I haven't been able to repro this. Is this isolated to nvidia GPUs possibly?

Sorry, I haven't had the time to test the latest release yet. I am using an Nvidia GPU though.

Last week I forked and locally built (successfully) with the cstdint header included, same as this commit from the next day. I will try the newest version shortly and see if it's been resolved (EDIT: no more build errors).

[b02860de585071a2]

Update on this:

With the most recent AUR version (0.6.9.1-2), the build errors have been resolved! So that's one part of the problem solved.

However, I am still experiencing the same behavior in regards to using the MANGOHUD=1 environment variable with Steam (games load indefinitely/will not launch, Steam refusing to exit cleanly).

What logs can I provide, or what information would be most helpful for you to diag this?

[awsms]

I was gonna nuke my OS and start from fresh because of this, then realized it was caused by mangohud...

With the most recent AUR version (0.6.9.1-2), the build errors have been resolved! So that's one part of the problem solved.

However, I am still experiencing the same behavior in regards to using the MANGOHUD=1 environment variable with Steam (games load indefinitely/will not launch, Steam refusing to exit cleanly).

Same here.

[flightlessmango]

If I run steam with mangohud steam then I can repro the game not starting.
I've noticed this error
pressure-vessel-adverb[262239]: E: Unable to create symlink /tmp/pressure-vessel-libs-QBF141/haswell/libMangoHud.so -> /run/host/usr/lib/mangohud/lib/libMangoHud.so: File exists
which seems to be the cause of the crash. @FAT9L Do you see this error as well?

[b02860de585071a2]

I've noticed this error
pressure-vessel-adverb[262239]: E: Unable to create symlink /tmp/pressure-vessel-libs-QBF141/haswell/libMangoHud.so -> /run/host/usr/lib/mangohud/lib/libMangoHud.so: File exists
which seems to be the cause of the crash. @FAT9L Do you see this error as well?

I do not. mangohud steam actually works perfectly...the overlay works in-game and everything. I assume this is equivalent to having mangohud %command% in launch options? Because that has always worked.

Here are some logs from steam, comparing the successful run (with mangohud steam) against a failed one (with MANGOHUD=1 steam, which consistently fails).

[flightlessmango]

This fixed the issue on my end f1b5ba3

[kodatarule]

This fixed the issue on my end f1b5ba3

Can confirm that the games are now launching perfectly fine, however I noticed that the steam process hangs when you attempt to exit it with mangohud globally enabled from goverlay.

EDIT: Further testing seems to have returned same behavior ... compiled latest mangohud through the AUR

[b02860de585071a2]

This fixed the issue on my end f1b5ba3

No change for me, after removing all old versions and doing a clean git clone + build from source. At a complete loss for what's different between our systems.

[flightlessmango]

Can you run steam with STEAM_LINUX_RUNTIME_LOG=1 STEAM_LINUX_RUNTIME_VERBOSE=1 and post the slr log here?
You can find it in the common/SteamLinuxRuntime_sniper/var

[toboggan7]

Both the issues with exiting Steam and launching games are present on my end. Here's my logs:
slr-app0-t20230603T113023 (d3ddriverquery.exe, from launching steam).log
slr-app3560-t20230603T113038 (test run of Bejeweled Twist on GE).log
slr-app3560-t20230603T113718 (Bejeweled Twist on Experimental).log

Proton GE is used by d3ddriverquery.exe, and I'm unsure as to why - the default is Experimental.

[flightlessmango]

I don't see anything interesting in those logs sadly.
Does this issue only happen with proton or does it happen on native games with steam runtime active?

[b02860de585071a2]

Can you run steam with STEAM_LINUX_RUNTIME_LOG=1 STEAM_LINUX_RUNTIME_VERBOSE=1 and post the slr log here? You can find it in the common/SteamLinuxRuntime_sniper/var

Logs here, uploaded one that failed (using MANGOHUD=1 STEAM_LINUX_RUNTIME_LOG=1 STEAM_LINUX_RUNTIME_VERBOSE=1 steam), and one that launched successfully (using STEAM_LINUX_RUNTIME_LOG=1 STEAM_LINUX_RUNTIME_VERBOSE=1 steam).

Does this issue only happen with proton or does it happen on native games with steam runtime active?

I've been testing with Poly Bridge 1 + 2, and also Half-Life, since all of them are very small installs and have a native version available.

• Native versions: will launch with the MANGOHUD=1 environment variable, but do not show the overlay and do not generate any logs of interest.

• Proton versions: exhibit the whole "hanging and not launching" behavior, and do generate logs.

Both native and Proton games run fine with the mangohud launch option (no environment variable). Clear as mud 👍

[flightlessmango]

You need to enable steam runtime with native games to test, it's in the same list as you enable proton.
I can see also you're not on the latest mangohud as he's trying to use glxinfo

[b02860de585071a2]

You need to enable steam runtime with native games to test, it's in the same list as you enable proton.

Misunderstood what you were asking for, sorry.

I do not get an slr log if I use the runtime instead of Proton, is there another one that's relevant? Behavior is the same as native otherwise.

I can see also you're not on the latest mangohud as he's trying to use glxinfo

Currently back on 0.6.9.1-6 from the AUR, but I can clean build from source on f1b5ba3 if matters.

[flightlessmango]

It's important that we minimize the differences when debugging

[b02860de585071a2]

You're right. I clean built from that commit, no change (and no logs).

[toboggan7]

I don't see anything interesting in those logs sadly. Does this issue only happen with proton or does it happen on native games with steam runtime active?

Proton and Vulkan only, it seems. Bejeweled 3 worked with WineD3D (no overlay). Aperture Desk Job, a Vulkan title (non-DXVK), refused to launch under Proton, but worked natively. Consistent with CS:GO, a native title which uses DXVK.

All tests mentioned were before f1b5ba3, unsure of exact commit. Tested on 9 May. Will retest if required.
Proton logs for Aperture Desk Job, in case they are of any use.

[flightlessmango]

@FAT9L

I clean built from that commit, no change (and no logs).

Are you saying it didn't produce any slr logs? doesn't sound like slr was activated or you need to look in a different slr folder, might be using soldier?

@ytfcon

All tests mentioned were before f1b5ba3, unsure of exact commit. Tested on 9 May. Will retest if required.

Please test with latest mangohud so we can make sure we don't have two different issues.
Can you also test native games with slr?

[b02860de585071a2]

might be using soldier?

Yep. Here are SLR logs for HL2 (Vulkan) and Poly Bridge 2 (OpenGL?).

Steam was started with MANGOHUD=1 STEAM_LINUX_RUNTIME_LOG=1 STEAM_LINUX_RUNTIME_VERBOSE=1 steam, on f1b5ba3, same as before.

[tazz4843]

I went through the same testing process @smcv did in their comment here: #1014 (comment).

Baseline: all good, PLAY turns to CANCEL, then STOP and the game launches, with the same screens visible (recommended on Steam Deck, main menu Controller Required, etc)
baseline-steam.log

Launch Options set to MANGOHUD=1 %command%: game hangs forever. PLAY turns to CANCEL and then to STOP, but after waiting about 90 seconds, no game window has appeared, so I hit the STOP button to terminate it.
options-MANGOHUD1-steam.log

Launch Options set to mangohud %command%: same as baseline, but MangoHud is visible.
options-mangohud-steam.log

Re-launching Steam with MANGOHUD=1 added to its environment, Aperture Desk Job launch options empty: PLAY turns to CANCEL, but hangs forever (over 120 seconds) there. Clicking CANCEL returns to PLAY instantly.
global-MANGOHUD1-steam.log

Re-launching Steam as PROTON_LOG=1 [...etc...] mangohud steam: same as setting Launch Options to MANGOHUD=1 %command%.
global-mangohud-steam.log

I did not set the runtime logs separately, instead used | tee steam.log with the STEAM_LINUX_RUNTIME_VERBOSE=1 env var set.

[tazz4843]

systemd-cgls output for the above:

│   │ │ ├─app-steam-app1902490-25626.scope (#10521)
│   │ │ │ ├─25626 /home/zero/.local/share/Steam/steamapps/common/SteamLinuxRuntime_sniper/pressure-vessel/bin/pv-bwrap --args 33 /usr/lib/pressure-vessel/from-host/bin/pressure-vessel-adverb --generate-locales --fd 22 --regenerate-ld.so-cache /run/pressure-vessel/ldso --add-ld.so-path /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu --add-ld.so-path /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu --set-ld-library-path /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/aliases:/usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/aliases --exit-with-parent --subreaper --shell=none --terminal=none --verbose -- /home/zero/.local/share/Steam/steamapps/common/SteamLinuxRuntime_sniper/pressure-vessel/bin/steam-runtime-launcher-interface-0 container-runtime /home/zero/.local/share/Steam/steamapps/common/Proton 8.0/proton run /home/zero/.local/share/Steam/legacycompat/iscriptevaluator.exe legacycompat\evaluatorscript_1902490.vdf
│   │ │ │ ├─25721 /usr/lib/pressure-vessel/from-host/bin/pressure-vessel-adverb --generate-locales --fd 22 --regenerate-ld.so-cache /run/pressure-vessel/ldso --add-ld.so-path /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu --add-ld.so-path /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu --set-ld-library-path /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/aliases:/usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/aliases --exit-with-parent --subreaper --shell=none --terminal=none --verbose -- /home/zero/.local/share/Steam/steamapps/common/SteamLinuxRuntime_sniper/pressure-vessel/bin/steam-runtime-launcher-interface-0 container-runtime /home/zero/.local/share/Steam/steamapps/common/Proton 8.0/proton run /home/zero/.local/share/Steam/legacycompat/iscriptevaluator.exe legacycompat\evaluatorscript_1902490.vdf
│   │ │ │ ├─25745 python3 /home/zero/.local/share/Steam/steamapps/common/Proton 8.0/proton run /home/zero/.local/share/Steam/legacycompat/iscriptevaluator.exe legacycompat\evaluatorscript_1902490.vdf
│   │ │ │ └─25746 c:\windows\system32\steam.exe /home/zero/.local/share/Steam/legacycompat/iscriptevaluator.exe legacycompat\evaluatorscript_1902490.vdf
│   │ │ ├─app-steam-app1902490-16699.scope (#10041)
│   │ │ │ ├─16788 /usr/lib/pressure-vessel/from-host/bin/pressure-vessel-adverb --generate-locales --fd 22 --regenerate-ld.so-cache /run/pressure-vessel/ldso --add-ld.so-path /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu --add-ld.so-path /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu --set-ld-library-path /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/aliases:/usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/aliases --exit-with-parent --subreaper --shell=none --terminal=none --verbose -- /home/zero/.local/share/Steam/steamapps/common/SteamLinuxRuntime_sniper/pressure-vessel/bin/steam-runtime-launcher-interface-0 container-runtime /home/zero/.local/share/Steam/steamapps/common/Proton 8.0/proton run /home/zero/.local/share/Steam/legacycompat/iscriptevaluator.exe legacycompat\evaluatorscript_1902490.vdf
│   │ │ │ ├─16813 c:\windows\system32\steam.exe /home/zero/.local/share/Steam/legacycompat/iscriptevaluator.exe legacycompat\evaluatorscript_1902490.vdf
│   │ │ │ ├─16815 /home/zero/.local/share/Steam/steamapps/common/Proton 8.0/dist/bin/wineserver
│   │ │ │ ├─16819 C:\windows\system32\services.exe
│   │ │ │ ├─16822 C:\windows\system32\winedevice.exe
│   │ │ │ ├─16832 C:\windows\system32\winedevice.exe
│   │ │ │ ├─16852 C:\windows\system32\plugplay.exe
│   │ │ │ ├─16858 C:\windows\system32\svchost.exe -k LocalServiceNetworkRestricted
│   │ │ │ ├─16864 C:\windows\system32\explorer.exe /desktop
│   │ │ │ ├─16973 C:\windows\system32\rpcss.exe
│   │ │ │ └─16983 C:\windows\system32\tabtip.exe

[gardotd426]

Running Wolfenstein: Youngblood to run under Proton 8.0 Experimental and the Soldier Runtime: Same bug.

Seems like you've got it right @smcv, that it might be Proton 8. I have to still try to run it with Proton 7 + Sniper, but yeah, Proton 8 + Soldier is the same as Proton 8 + Sniper.

[gardotd426]

Proton 7 + Sniper + MANGOHUD=1 works.

[Bobbydigital420]

Can confirm that running with steam-runtime-launch-options -- %command%

Proton 7 launches fine with both Solder and Sniper runtimes using the mangohud command and MANGOHUD=1 variable

Proton 8 is broken using both runtimes with the MANGOHUD=1 variable, works fine for both runtimes with mangohud command

[smcv]

This seems to be related to having SteamVR installed. vrclient.so is mentioned in the crash dump for the crash I saw, and if it's installed, Proton loads it during game startup. Both Proton 7 and 8 do that, so I don't know why only Proton 8 is showing the crash or hang.

As far as I can tell, the factors required to trigger this are:

• Proton 8
• MANGOHUD=1
• not using the mangohud script (mangohud %command% or similar)
• NVIDIA GPU + proprietary driver (I couldn't reproduce this with AMD/Mesa)
• Arch, or maybe other recent rolling-release distros with gcc 13 runtime libraries (I couldn't reproduce this on Ubuntu 22.04 on the same hardware)
• SteamVR installed

The workaround that preserves most functionality will be to use the mangohud script in preference to MANGOHUD=1.

I don't know why I see a crash (game exits) when other people see a hang (a process waits forever), but if this is memory corruption or something, then either one is a possible symptom.

Proton 8 is broken using both runtimes with the MANGOHUD=1 variable

@Bobbydigital420, to confirm, what does "broken" currently mean for you - a process hanging, or a process crashing?

[gardotd426]

It's not SteamVR. I just completely removed it. Dying Light 2 is still showing the same behavior.

[gardotd426]

Just tried Wolfenstein 2 with SteamVR removed as well:

Proton 7.X + Soldier: Works
Proton 7.X + Sniper: Works
Proton 8.X + Soldier: Same bug
Proton 8.X + Sniper: Same bug

I've got another appointment this morning but I'll try to get the Steam Runtime logs or whatever when I get home so we can find out more about what's going on.

[flightlessmango]

Once I installed SteamVR I could finally reproduce games crashing. Uninstall SteamVR fixes the issue again.
Since it didn't work for @gardotd426, I'm guessing that points to two different issues here

[gardotd426]

I just got home, I'm not sure how exactly it could be two different issues, since the results are literally exactly the same (Proton 8.X + Sniper or Soldier + MANGOHUD=1: games break, Proton 7.X + Sniper or Soldier + MANGOHUD=1: games work fine).

But, you guys know more than I do for sure, so I can try to grab those steam runtime logs to better help confirm what the issue is.

[flightlessmango]

@gardotd426

It's not SteamVR. I just completely removed it.

On my end SteamVR introduced and fixes the bug, that's the difference

[Bobbydigital420]

This seems to be related to having SteamVR installed. vrclient.so is mentioned in the crash dump for the crash I saw, and if it's installed, Proton loads it during game startup. Both Proton 7 and 8 do that, so I don't know why only Proton 8 is showing the crash or hang.

As far as I can tell, the factors required to trigger this are:

* Proton 8

* `MANGOHUD=1`

* _not_ using the `mangohud` script (`mangohud %command%` or similar)

* NVIDIA GPU + proprietary driver (I couldn't reproduce this with AMD/Mesa)

* Arch, or maybe other recent rolling-release distros with gcc 13 runtime libraries (I couldn't reproduce this on Ubuntu 22.04 on the same hardware)

* SteamVR installed

The workaround that preserves most functionality will be to use the mangohud script in preference to MANGOHUD=1.

I don't know why I see a crash (game exits) when other people see a hang (a process waits forever), but if this is memory corruption or something, then either one is a possible symptom.

Proton 8 is broken using both runtimes with the MANGOHUD=1 variable

@Bobbydigital420, to confirm, what does "broken" currently mean for you - a process hanging, or a process crashing?

The process hangs for me until I hit stop. I also have a VR headset and uninstalling SteamVR doesn't work for me either, process still hangs.

[gardotd426]

Along with myself and @Bobbydigital420, Ryan from Intelligent-Gaming (the YT channel, that's his Reddit handle too) also is able to reproduce this and doesn't have SteamVR installed.

I asked him to check and see if he had SteamVR:

So, just updated mangohud from the AUR to make sure I had the absolute latest code, then tried to launch Wolfenstien: Youngblood after launching Steam with:

PROTON_LOG=1 \
PRESSURE_VESSEL_SYSTEMD_SCOPE=1 \
STEAM_LINUX_RUNTIME_VERBOSE=1 \
steam 2>&1 | tee steam.log

Still wasn't showing any real errors in the console output when I try to launch the game, and the only mention of SteamVR is (obviousy) one line that says it's not initializing SteamVR because it isn't installed.

Once Steam opened, I tried to launch Wolfenstein: Youngblood with MANGOHUD=1 and the Sniper Runtime using Proton Experimental (Bleeding Edge). Game didn't launch, after about a minute I clicked Stop and then when that was done and the green Play button re-appeared I exited Steam to try and keep the log as relevant as possible. I couldn't see much but hopefully you guys can find something.

steam.log

[rokam]

I do have the same issue here and I don't have VR. This isn't related to VR.

[flightlessmango]

This change isn't specifically related to this issue but I think it's worth to try 602ba78

[Saancreed]

Unfortunately even the latest master is still broken for me, e.g. here's a log from Warframe hanging when launched with MANGOHUD=1 on Proton Experimental without Sniper Runtime (has to be killed from Steam afterwards): steam-230410.log

One workaround that makes it work again is building with -static-libstdc++ which kinda works in this case but that's, uhh, not exactly an optimal solution 🙈

[flightlessmango]

One workaround that makes it work again is building with -static-libstdc++

Let's try it out and hopefully it works for most. dc1761e

[gardotd426]

Yep, seems to work:

[gardotd426]

Only tried one game so far but it loaded up immediately

[Bobbydigital420]

Tried it with 3-4 games and everything is working fine here for me!

[flightlessmango]

@FAT9L can you confirm if this works too?

[kodatarule]

One workaround that makes it work again is building with -static-libstdc++

Let's try it out and hopefully it works for most. dc1761e

It seems to have resolved the problem, no issues here.

[flightlessmango]

Closing as resolved

[Bitwolfies]

We mightttt have to reopen this issue. I've encountered one game on steam https://store.steampowered.com/app/1151740/Prison_Princess/ that fails to launch with the env variable added. Other games I have installed atm work fine with it, but not this one.

[flightlessmango]

If it's just with one game then I don't think it's this issue

[b02860de585071a2]

@FAT9L can you confirm if this works too?

My apologies for not getting back to you sooner, life has been getting in the way.

---

Yes, clean building from dc1761e seems to resolve the issue entirely - as does the latest mangohud-git from the AUR (currently 0.6.9.1.r84.gbc8acf9-2).

I tested and confirmed using the same setup as before:

• export MANGOHUD=1 in .profile, -OR- MANGOHUD=1 steam from a terminal
• Native games (HL1, CS:GO)
• Games forced to use Steam Linux Runtime (Poly Bridge 1, HL2)
• Proton games (Apex Legends, Overwatch 2)

All launched and showed the overlay as expected, no errors. Native games do require mangohud %command% in launch options, but that has always been the case. Setting the environment variable MANGOHUD=1 does not conflict with this.

I would consider this fixed, and safe to ship with the next release. 😄

---

Minor problem that probably doesn't warrant a new issue?

There is only one problem I'm encountering - text rendering seems to be slightly messed up when using an alpha value below 1.0 on dc1761e or mangohud-git. Screenshots are shown below, all using alpha=0.4 in their config files.

CS:GO main menu, mangohud 0.6.9.1-10:

CS:GO main menu, dc1761e:

Apex main menu, mangohud 0.6.9.1-10:

Apex main menu, dc1761e:

It is most noticable on the dividers between sections, however text outlines are affected too. This has been ongoing, but I left it out as it wasn't relevant to the discussion at hand.

If this is user error - or just irrelevant - let me know and I will remove it.