Open DonKatsu opened 1 month ago
the ld error is strange to see in this context, I would like to see the full error. I have added debug logs for this in this commit 511b7a6f2a4c08515c7ff932a4db8fed4c964c57. It would be helpful if you could
MANGOHUD_LOG_LEVEL=debug PROTON_LOG=1 mangohud %command%
Sure, here. steam-2132850.log
I also launched Steam from a console to see the debug output with Zomboid (Native), and Steam (runtime and native) was spamming ERROR: ld.so: object '/usr/lib32/libextest.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
while starting. (Zomboid had the same debug output.)
https://github.com/ValveSoftware/steam-for-linux/issues/10771 might have something to do with it? I'm not sure what would be doing that however. Oh, libextest is a thing for Steam controller support on wayland? CachyOS does include it as a dependency with Steam since the 9th of this month. So I've had it prior to mangohud 0.7.2, which still had working exec output.
I believe that's either an issue with your system or with the steam runtime
I tried clean installs of EndeavourOS and CachyOS. After each install I only did pacman -Syu steam steam-native-runtime mangohud lib32-mangohud
and restarted.
On Endeavour with Proton 9.0-1, exec worked as expected with multilib/steam runtime/native. However a native game (Brigador) was showing the same cut off error as my existing Cachy install.
On the clean Cachy install, it was showing all of the same cut off error messages with Proton and Native using cachyos/steam and/or proton-cachyos.
After that I did some trial and error on my existing Cachy install and found: cachyos/steam (runtime/native) with any proton=Error exec multilib/steam (runtime/native) with proton 9.0-1=Correct exec multilib/steam (runtime/native) with proton-cachyos=Error exec multilib/steam or cachyos/steam (runtime/native) with native games=Error exec
Native Zomboid shows the same error exec as native Brigador when launched through Steam. But when launched outside of Steam it has a different error that still includes the output of uname -r
, but cut off too. Example.
When using multilib/steam which doesn't have the LD_PRELOAD for libextest.so, the "debug received output" changes to the similar preload "error" for gameoverlayrenderer.so.
I'm just guessing, but it looks like the updated exec is grabbing one of those "errors" before the uname -r
which I see are still printed underneath them in the log? Not sure why cachyos/steam or proton-cachyos would cause it to do that.
I do know proton-cachyos is compiled against system libraries, but I'm not sure about cachyos/steam itself.
With mangohud downgraded to 0.7.1, its exec still works with any combo that involves a CachyOS version of steam/proton.
As mentioned above native Zomboid has shown a different error in the exec output both through Steam and not. Example.
It started sometime between 0.7.0 and 0.7.1, so it shouldn't be from mangohud itself?
Native Brigador shows the output of uname -r
as expected either way.
I've rewritten the function a bit so we only get the last line a4393e0e4222374afa024203eb5dee9c3540bba3
Hopefully this will resolve the issue
Same issue is happening with a clean arch install in two machines. LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32) when launching using Proton (Experimental, 8.0 or 9.0)
Installing from AUR results in same error. Uninstalling or not using mango hid when launching works in any game.
In my case I’m using gamescope-session which try to run mangohud session wide. Tested in desktop mode forcing steam launch parameters also producing same error.
In my case I’m using gamescope-session
Unrelated to this issue, but you shouldn't use mangohud with gamescope, instead use mangoapp
Uninstalling or not using mango hid when launching works in any game.
I don't understand, this error does not have any consequences. If using mangohud prevents your game from starting then you have a different issue
In my case I’m using gamescope-session
Unrelated to this issue, but you shouldn't use mangohud with gamescope, instead use mangoapp
Uninstalling or not using mango hid when launching works in any game.
I don't understand, this error does not have any consequences. If using mangohud prevents your game from starting then you have a different issue
I think mangoapp is discontinued. Running steam via console in Desktop mode and trying to launch with mangohud isn’t starting the game. Exiting in silence. The only thing in logs is this ERROR.
Not using mangohud at all, doesn’t result in silent game quitting.
My I should inspect any other file from mangohud or my system to try to identify more valuable information what’s going on?!
Thanks in advance
Edit: I managed to get a form of error log launching steam and dumping debug logs: [MANGOHUD] [error] [overlay_params.cpp:144] Couldn’t create socket pipe at ‘mangohud’ [MANGOHUD] [error] [overlay_params.cpp:115] Address already in use
Would it be related to mangouud somehow? (I’m using mangohud-git AUR package at this moment)
I think mangoapp is discontinued.
That would be news to me, being the developer and all. mangoapp is developed in this repo and completely dependent on mangohud. When mangohud updates, mangoapp updates. mangohud is not supported for use with gamescope, it will cause issues. You should do the same as steamos does, running mangoapp in gamescope-session
[MANGOHUD] [error] [overlay_params.cpp:144] Couldn’t create socket pipe at ‘mangohud’ [MANGOHUD] [error] [overlay_params.cpp:115] Address already in use
These shouldn't be errors, they will not prevent the game from running. You need to use mangoapp.
All of this is unrelated to this issue. Please create a new issue if mangoapp doesn't work
I think mangoapp is discontinued.
That would be news to me, being the developer and all. mangoapp is developed in this repo and completely dependent on mangohud. When mangohud updates, mangoapp updates. mangohud is not supported for use with gamescope, it will cause issues. You should do the same as steamos does, running mangoapp in gamescope-session
[MANGOHUD] [error] [overlay_params.cpp:144] Couldn’t create socket pipe at ‘mangohud’ [MANGOHUD] [error] [overlay_params.cpp:115] Address already in use
These shouldn't be errors, they will not prevent the game from running. You need to use mangoapp.
All of this is unrelated to this issue. Please create a new issue if mangoapp doesn't work
Ok. I will open a new issue because is logging these errors when using command line on steam client on Desktop. Thanks
I've rewritten the function a bit so we only get the last line a4393e0
This seems to do the trick for me.
With cachyos/steam and proton-cachyos, exec=uname -r
is displaying correctly with most of my installed games.
(32 bit games excluded until lib32-mangohud gets that, of course.)
Native games are showing exec properly as well. Zomboid even stopped showing the XInitThreads.cpp thing so that's nice.
After I first updated mangohud-git and restarted cachyos/steam (native) to be safe, the first launch of Rabbit and Steel was fine.
But closing and launching it again had the error exec again. After that, further launches, and native games also had the error exec.
1-FirstLaunch-steam-2132850.log 2-SecondLaunch-steam-2132850.log
First log's debug looks like what you'd want? But the second log only has the single preload error for received output, and no uname -r
results at all.
I'm not sure what happened there, but so far it hasn't happened again after further restarts of Steam.
Oops, had an instance where going from Proton to a native game had the native games show the error exec again. But the game started first with Proton still shows the correct output while other games with Proton also show the error.
Restarting Steam fixed it again, but that seems to be temporary?
A user on the CachyOS Discord server mentioned that while exec=uname -r
was also showing them an error, exec=echo $XDG_SESSION_TYPE
still worked for them. This is also the true for me with release mangohud 0.7.2..
Example. Log using mangohud-git-0.7.2.r4.g511b7a6-1 steam-2132850.log
I'm guessing what's happening is that every program is being LD_PRELOADED with mangohud and steamoverlay which prints these errors. I've tried to handle this by just ignoring all these errors eaa96ecfba7835054cdacd9534bbbaf08fa7eef1
Oh of course, the solution was always to just unset LD_PRELOAD
..
41f2cf74de38ac4a2d84d85642c107b75c54f359 this commit should resolve this issue
Seems good so far, but I haven't put too much time in with it yet.
Though I am seeing rare flashes of a new message. Example. steam-2132850.log
Shell: recieved output: sh: line 696: 477410 Bad system call LD_PRELOAD= uname -r
I think my mangohud-git is updated? Not completely sure, paru keeps telling me there's an update then immediately tells me the new version up to date, skips the build and reinstalls the current version instead? mangohud --version v0.7.2-10-g41f2cf7
This might be a better solution f8fb9aaa7d6cdfb10005122c7051a1b883c9228f
mangohud-git updated: mangohud --version v0.7.2-11-gf8fb9aa
That message now shows as Shell: recieved output: /bin/sh: line 377: 682590 Bad system call uname -r
on cachyos/steam with proton-cachyos. Line number still different each time.
Tried multilib/steam (Runtime) with standard Proton 9.0-1 and it shows as just Shell: recieved output: Bad system call
Not sure if this might still be relevant, but with 0.7.1 the uname -r
result would occasionally blank for a few frames. Seems kind of similar, how these are printed for that single exec update?
Also tried letting vkcube run for an hour with MANGOHUD_LOG_LEVEL=debug mangohud vkcube &> output.txt
but no received output messages other than the uname -r
output came up.
Yet another attempt to fix this c0afb84e9c9369acabf0f7bf0214517c2defe25a
multilib/steam (runtime) with Proton 9.0-2b, still seeing instances of Shell: recieved output: Bad system call
.
Installed the standard Arch kernel and still see instances of that message, so I suppose that would rule out Cachy kernel patches?
steam-2132850.log
mangohud --version v0.7.2-26-gc0afb84
Can you test if it happens with something more basic? like cat a file in your home directory
To date I haven't had any issues with cat, or anything else terminal based returning Bad system call
or whatever if that's what you mean. By the way, I'm using fish as my shell which is the CachyOS default. Not sure if that might matter?
And mangohud attached to vkcube outside of steam still doesn't seem to return anything other than the uname -r
output.
I finally got around to playing a native game through Steam, Brigador. Launched Steam through a terminal with the output going to a text file to capture Brigador's mangohud debug output.
After 30 minutes each with Steam runtime and native, I didn't get any instances of Shell: recieved output: Bad system call
.
So something to do with Proton, then?
Editing in another observation:
A bit after I opened this issue, CachyOS released wine-cachyos, forked from Valve's Wine.
Since I switched to it I hadn't been keeping an eye for instances of Bad system call
but after doing so today I do see it happening, as the Shell: recieved output: /bin/sh: line 1444: 203874 Bad system call uname -r
type.
Switching back to standard Wine, I didn't see any instances of Bad system call
after an hour.
I used a new prefix for both tests, with the same Unity game.
8f94973cd899f43cc1f7ee09c29229a712cd2377 yet another attempt
I should say, log might still say "bad system call" but it shouldn't be shown in the hud
Yep, that works. Screenshot
Still curious why it only happens with Proton and Proton derivatives, but I suppose this can be closed with that workaround.
Describe the bug exec returns a cut off error message inside mangohud on games launched through Steam. Tried with both steam-runtime and steam-native. Games ran through Proton as well as Native Linux titles both show the same error.
List relevant hardware/software information
To Reproduce Steps to reproduce the behavior:
exec=uname -r
is used in my examples, but it doesn't matter what.mangohud %command%
.Expected behavior exec command printed.
Screenshots Example with a game launched with Proton. What should be the output of
custom_text=Kernel exec=uname -r
instead showsld so object '/usr/lib3
. Example of exec still working with vkcube. (Not with Steam of course.)Additional context Games launched with mangohud through system Wine (with or without Lutris) still give proper exec output.