ValveSoftware
Action Henk crashes on AMD Systems with default "Steam Linux Runtime 1.0"
Your system information
-
Steam Beta Branch: Stable Client/ Steam Version: 1747701111
-
Link to your full system information https://gist.github.com/CaptainCoward/0abea6a5b1f1bb8373cdf4bd67bcde81
-
Have you checked for system updates?: [Yes]
-
What compatibility tool are you using?: [Steam Linux Runtime 1.0 (scout)]
-
What versions are listed in
steamapps/common/SteamLinuxRuntime/VERSIONS.txt? 0.20240806.0
Please describe your issue in as much detail as possible:
I have seen the same issue on 2 of my AMD Systems (AMD GPU and AMD CPU) but not on my Intel/NV system, where it seems to work fine.
On AMD when using Steam Linux Runtime 1.0 (Scout) which is selected by default: The Game starts, then loads and suddenly gets stuck/freeze during loading. Waiting for a while will eventually end in a Black Screenm while the Game Music starts playing. All you then can do is close/kill the game.
Checking the Journal i can see the following errors:
Process 3938 (ActionHenk.x86_) of user 1000 dumped core.
Module /run/host/usr/lib/libicudata.so.76.1 without build-id.
Module /run/host/usr/lib/libicudata.so.76.1
Module /run/host/usr/lib/libicuuc.so.76.1 without build-id.
Module /run/host/usr/lib/libicuuc.so.76.1
Stack trace of thread 3938:
#0 0x00007373de6a774c n/a (/run/host/usr/lib/libc.so.6 + 0x9774c)
#1 0x00007373de64ddc0 n/a (/run/host/usr/lib/libc.so.6 + 0x3ddc0)
#2 0x00007373de63557a n/a (/run/host/usr/lib/libc.so.6 + 0x2557a)
#3 0x00007373dc4917f2 n/a (libmono.so + 0x917f2)
#4 0x00007373dc43483b n/a (libmono.so + 0x3483b)
#5 0x00007373de64def0 n/a (/run/host/usr/lib/libc.so.6 + 0x3def0)
#6 0x00007373d9360037 n/a (/run/host/usr/lib/libgallium-25.1.1-arch1.1.so + 0x560037)
#7 0x00007373d931a1d7 n/a (/run/host/usr/lib/libgallium-25.1.1-arch1.1.so + 0x51a1d7)
#8 0x00007373d931a26c n/a (/run/host/usr/lib/libgallium-25.1.1-arch1.1.so + 0x51a26c)
#9 0x00007373de6505e1 n/a (/run/host/usr/lib/libc.so.6 + 0x405e1)
#10 0x00007373de6506be n/a (/run/host/usr/lib/libc.so.6 + 0x406be)
#11 0x0000000000c0d316 n/a (/data/Gplatte/SteamLibrary/steamapps/common/Action Henk/ActionHenk.x86_64 + 0x80d316)
#12 0x0000000000ba0c7e n/a (/data/Gplatte/SteamLibrary/steamapps/common/Action Henk/ActionHenk.x86_64 + 0x7a0c7e)
#13 0x0000000040ceea1c n/a (n/a + 0x0)
#14 0x000000004062e05f n/a (n/a + 0x0)
#15 0x00007373dc4389cb n/a (libmono.so + 0x389cb)
#16 0x00007373dc533bad mono_runtime_invoke (libmono.so + 0x133bad)
#17 0x0000000000774faa n/a (/data/Gplatte/SteamLibrary/steamapps/common/Action Henk/ActionHenk.x86_64 + 0x374faa)
#18 0x000000000075e1bd n/a (/data/Gplatte/SteamLibrary/steamapps/common/Action Henk/ActionHenk.x86_64 + 0x35e1bd)
#19 0x000000000075f2d4 n/a (/data/Gplatte/SteamLibrary/steamapps/common/Action Henk/ActionHenk.x86_64 + 0x35f2d4)
#20 0x00000000005d5d36 n/a (/data/Gplatte/SteamLibrary/steamapps/common/Action Henk/ActionHenk.x86_64 + 0x1d5d36)
#21 0x00000000006f286e n/a (/data/Gplatte/SteamLibrary/steamapps/common/Action Henk/ActionHenk.x86_64 + 0x2f286e)
#22 0x000000000042e09e n/a (/data/Gplatte/SteamLibrary/steamapps/common/Action Henk/ActionHenk.x86_64 + 0x2e09e)
#23 0x00007373de6376b5 n/a (/run/host/usr/lib/libc.so.6 + 0x276b5)
#24 0x00007373de637769 n/a (/run/host/usr/lib/libc.so.6 + 0x27769)
#25 0x000000000042f891 n/a (/data/Gplatte/SteamLibrary/steamapps/common/Action Henk/ActionHenk.x86_64 + 0x2f891)
ELF object binary architecture: AMD x86-64
Steps for reproducing this issue:
- Download the game Action Henk
- Check if the default Steam Linux Runtime 1.0 (Scout) is selected
- Start game.
Aditional Info
The issue seems to be exclusive in combination of AMD/AMD + Steam Linux Runtime 1.0 (scout). The Legacy Runtime appears to be working fine.
On my other Intel(CPU)/NV System both runtimes seem to work as they should.
Steam Linux Runtime 2.0 and 3.0 aren't able to be selected (no clue if this is normal).
According to https://steamdb.info/app/285820/info/, on Steam Deck this game defaults to having its Windows version run under Proton, which suggests that the native Linux version may already have had known issues.
Steam Linux Runtime 2.0 and 3.0 aren't able to be selected (no clue if this is normal)
This is normal and intended. If a game's developer has not configured their game as targeting SLR 3.0, then the only safe/conservative backward-compatible assumption is that it is targeting the legacy Steam Runtime 1.0 library stack based on Ubuntu 12.04, for which the only implementations are:
- Steam Linux Runtime 1.0 (actually a Steam Runtime 2 container plus Steam Runtime 1.0 compatibility glue)
- or Legacy Runtime 1.0 (whatever libraries happen to be available on the host system, plus Steam Runtime 1.0 compatibility glue)
SLR 2.0 is not available for native Linux games at all, to stop the number of possible configurations from becoming excessive. If game developers are interested in recompiling their game on a new runtime then they should target SLR 3.0 instead.
In your system info, this looks odd:
<3>pv-adverb[23861]: E: Failed to execute child process “/data/Gplatte/SteamLibrary/steamapps/common/SteamLinuxRuntime_soldier/pressure-vessel/bin/steam-runtime-launcher-interface-0” (No such file or directory)
... but then there's a successful diagnostic report for SteamLinuxRuntime_soldier. Perhaps you were unlucky with the timing, and were running the diagnostic tool while Steam was updating SteamLinuxRuntime_soldier at the same time?
The issue seems to be exclusive in combination of AMD/AMD + Steam Linux Runtime 1.0 (scout). The Legacy Runtime appears to be working fine. ... On my other Intel(CPU)/NV System both runtimes seem to work as they should.
This might be a bad interaction between your system's version of Mesa (which is used for AMD GPUs) and something in the container environment. On the Nvidia system, presumably you're using Nvidia's proprietary driver rather than Mesa, which would hide any Mesa issues.
Or it could be a game bug, or a Mesa bug, or a combination of factors - we can't really tell from here.
Are you able to report this to the game's developer/publisher via whatever support contact they provide?
In the backtrace from the crash, it's interesting that the call stack is weaving between libc, libgallium (Mesa) and the game's libmono. This might be legitimate, but it also might indicate that libmono is interposing some symbol in a way that isn't intended (or even in a way that is intended, but no longer works).
If you're able to get a more detailed backtrace using coredumpctl (see https://wiki.archlinux.org/title/Core_dump#Analyzing_a_core_dump) then that might shed some more light on this.
The Legacy Runtime appears to be working fine
The problem with the legacy runtime is that the best any of us can say about it is that it works fine for this game, on your system, today. Because you're using a fast-moving rolling release (it appears to be an Arch derivative) and the legacy runtime has very limited isolation between the fast-moving host system and the game, it's difficult to be confident that a game that works today will still work in future.
Hey, thank you for looking into this!
Perhaps you were unlucky with the timing, and were running the diagnostic tool while Steam was updating SteamLinuxRuntime_soldier at the same time?
I don't think so but i still do get the same when running the diagnostic tool. On my other (AMD) system i don't have it, Yet there it isn't working neither. However i fixed that now by reinstalling that runtime. Issue remains though.
According to https://steamdb.info/app/285820/info/, on Steam Deck this game defaults to having its Windows version run under Proton, which suggests that the native Linux version may already have had known issues.
That is interesting. I didn't know that you can see the recommended Deck-Runtime here. On Desktop it defaults to Steam Linux Runtime 1.0 at least it does so on my systems.
If you're able to get a more detailed backtrace
I tried following the instructions but it seems like most debug symbols are missing. Did i do something wrong? I'll post it anyways in case it is still helpful. But honestly, as you said if this already is known to have issues and already defaults to proton on the deck i might be better off just using proton then :D
warning: Could not load shared library symbols for 74 libraries, e.g. /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/libdl.so.2.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
Core was generated by `/data/Gplatte/SteamLibrary/steamapps/common/Action Henk/ActionHenk.x86_64'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007268276a774c in ?? ()
(gdb) bt
#0 0x00007268276a774c in ?? ()
#1 0x00007267bc1ef301 in ?? ()
#2 0x0000000000000004 in ?? ()
#3 0x000000000000001c in ?? ()
#4 0x8e3bad9bd55f8700 in ?? ()
#5 0x000007ed000000e4 in ?? ()
#6 0x0000000000000006 in ?? ()
#7 0x00000000017ddd58 in stdout ()
#8 0x000000000000000c in ?? ()
#9 0x00007ffe0a26c7e0 in ?? ()
#10 0x000072682764ddc0 in ?? ()
#11 0x0000003000000020 in ?? ()
#12 0x00007268255b15a8 in ?? () from /data/Gplatte/SteamLibrary/steamapps/common/Action Henk/ActionHenk_Data/Mono/x86_64/libmono.so
#13 0x00007ffe0a26c8a0 in ?? ()
#14 0x000072682763557a in ?? ()
#15 0x00007268255b160b in ?? () from /data/Gplatte/SteamLibrary/steamapps/common/Action Henk/ActionHenk_Data/Mono/x86_64/libmono.so
#16 0x000000000000000c in ?? ()
#17 0x00007ffe0a26c830 in ?? ()
#18 0x00007268255b15a8 in ?? () from /data/Gplatte/SteamLibrary/steamapps/common/Action Henk/ActionHenk_Data/Mono/x86_64/libmono.so
#19 0x0000000000000000 in ?? ()
(gdb)
On Desktop it defaults to Steam Linux Runtime 1.0 at least it does so on my systems.
Yes, most native Linux games default to SLR 1.0 on generic desktop Linux - it's only Steam Deck (or perhaps only SteamOS) that has this override.
if this already is known to have issues and already defaults to proton on the deck i might be better off just using proton then
Yes. (Or the legacy runtime, but that won't necessarily continue to work after OS upgrades.)
I tried following the instructions but it seems like most debug symbols are missing. Did i do something wrong? I'll post it anyways in case it is still helpful.
Hmm, yes, the fact that the core dump was generated inside the container, but you are doing post-mortem debugging outside the container, probably means some extra steps are needed to tell gdb what libraries and debug symbols to use.
Please use one of the workarounds for now (either use Proton or use the legacy runtime); and if you're willing to retry this under SLR 1.0 in future, I'll try to put together better instructions for examining core dumps from containerized games.
the fact that the core dump was generated inside the container, but you are doing post-mortem debugging outside the container, probably means some extra steps are needed to tell gdb what libraries and debug symbols to use
OK, this is pretty horrible (gdb doesn't support this use case particularly well) but bear with me...
- Set the game to run under SLR 1.0
- Set the game's Launch Options to
PRESSURE_VESSEL_SHELL=instead %command% - Launch the game: instead of actually getting the game, you'll get an
xterminside the container - In the
xterm, run this command to get the process ID of the shell inside the container:echo $$ - Make a note of the process ID (in my case it was 9940)
- Still in the
xterm, run this command, including the quotes:"$@" - If you have to do anything special to make the game crash, do it now (I don't have this game, so I sent
SIGQUITto a different game process to simulate a crash) - Leave the
xtermrunning: we need this as a way to access what's inside the container - In a separate shell on the host,
export DEBUGINFOD_URLS="https://debuginfod.steamos.cloud https://debuginfod.archlinux.org"- (if your distro EndeavourOS has its own separate debuginfod, add that URL too)
- Still in that same shell,
coredumpctl debug --debugger-arguments=--early-init-eval-command='set\ sysroot\ /proc/9940/root'replacing 9940 with the process ID of the shell in the container - ... and now commands like
btshould hopefully work better