search

ValveSoftware / steam-runtime

A runtime environment for Steam applications
Other
1.18k stars 86 forks source link

Shadowrun Returns (234650) crashes on launch #371

Open Newbytee opened 3 years ago

Newbytee commented 3 years ago

Your system information

Please describe your issue in as much detail as possible:

Shadowrun Returns crashes on launch when using Pressure Vessel. It works fine when not using it. This sounds like what's described in https://github.com/ValveSoftware/steam-runtime/issues/317, but that issue was fixed and I'm still seeing it. For what it's worth I'm on the client_beta branch of Steam Linux Runtime.

Log: https://github.com/ValveSoftware/steam-runtime/files/6049882/slr-app234650-t20210226T130344.log

Steps for reproducing this issue:

  1. Launch Shadowrun Returns
  2. Observe that it closes/crashes on launch

(Note: The game works fine if I launch it outside of Pressure Vessel)

RyuzakiKK commented 3 years ago

Can you please provide a pressure-vessel log? Here you can find the instructions on how to obtain it https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md#essential-information

smcv commented 3 years ago

I think this is probably https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/issues/46. Some games, like this one, assume they will be run with their current working directory in the library search path, because Steam used to do this (unintentionally, I think) and the game's developers started relying on it.

Newbytee commented 3 years ago

Can you please provide a pressure-vessel log? Here you can find the instructions on how to obtain it https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md#essential-information

Oops, yeah, I actually produced one and forgot to attach it. Here you go: slr-app234650-t20210226T130344.log

smcv commented 3 years ago

This might be fixed in today's beta update, depending whether my guess at the root cause was correct. Please check SteamLinuxRuntime/VERSIONS.txt after updating: it should say that you have pressure-vessel version 0.20210309.0+srt1.

Newbytee commented 3 years ago

It does launch now!

Some issues though:

Should I make new issue(s) for this? Neither of these issues are present if I launch it outside of Steam Linux Runtime/Pressure Vessel.

smcv commented 3 years ago

Since nobody else has jumped in on this issue, I think we can repurpose it for those remaining bugs. If we can understand why one of them happens but not the other, we might want to split them later.

Please send updated system info and logs.

Newbytee commented 3 years ago

System info: https://gist.github.com/Newbytee/70581067dd99a81e7f149b449064e510 Log: slr-app234650-t20210310T163600.log

Log was gathered like this: Game launched, and after reaching the main menu the in-game quit sequence (i.e. quit and then confirm) was done thrice (I was thinking this might help any potential patterns to show). After that, the game was exited by pressing the X in the GNOME window overview. The title screen is supposed to play music but none could be heard (as expected).

smcv commented 3 years ago

Does sound work OK for you in other games running under SLR?

smcv commented 3 years ago 
16:36:00.291781: _v2-entry-point[21675]: argv: /mnt/storage/SteamLibrary/steamapps/common/Shadowrun\ Returns/Shadowrun -logFile output.txt

Is there anything interesting in output.txt?

smcv commented 3 years ago 
"scout runtime container" information:
{
  "can-write-uinput" : true,
  "steam-installation" : {
    "path" : null,
    "data_path" : null,
    "bin32_path" : null,
    "steamscript_path" : "/usr/bin/steam",
    "steamscript_version" : "1.0.0.68",
    "issues" : [
      "cannot-find",
      "dot-steam-steam-not-symlink",
      "cannot-find-data",
      "dot-steam-steam-not-directory",
      "dot-steam-root-not-symlink",
      "dot-steam-root-not-directory",
      "missing-steam-uri-handler",
      "unexpected-steam-uri-handler"
    ]
  },

This could be significant: it looks as though ~/.steam and/or ~/.local/share/Steam didn't make it into the scout container. They seem OK in the soldier container, so this could be a recent regression.

Would you mind capturing a new log with environment variable STEAM_LINUX_RUNTIME_VERBOSE=1 set?

RyuzakiKK commented 3 years ago

This could be significant: it looks as though ~/.steam and/or ~/.local/share/Steam didn't make it into the scout container. They seem OK in the soldier container, so this could be a recent regression.

I'm able to reproduce this issue, for both Scout and Soldier. I'm checking the logs to see if I can spot what is causing it.

Newbytee commented 3 years ago

Does sound work OK for you in other games running under SLR?

Generally, yes. There is one exception which is Don't Starve Together (unless this has been fixed since I last tested it), but I imagine that's a game-specific issue. Audio works fine in games running via Proton 5.13 and CS:GO and Back to Bed. I haven't experienced audio issues with Steam Linux Runtime in any other games that I can recall.

Is there anything interesting in output.txt?

Not sure about audio, but there is something that seems relevant to the inability to quit. It seems it isn't able to find its own process or something like that. The log doesn't seem to contain any personal information, so I'll attach the entire thing: output.txt

Would you mind capturing a new log with environment variable STEAM_LINUX_RUNTIME_VERBOSE=1 set?

Should I still do this seeing as RyuzakiKK is on it?

smcv commented 3 years ago 
ALSA lib pcm_dmix.c:1029:(snd_pcm_dmix_open) unable to open slave

Are you intentionally using ALSA dmix, or is that a bug?

Newbytee commented 3 years ago 
ALSA lib pcm_dmix.c:1029:(snd_pcm_dmix_open) unable to open slave

Are you intentionally using ALSA dmix, or is that a bug?

I'm not even sure what ALSA dmix is, so I don't think so. I do know what ALSA is, but I should be using PulseAudio. Unless Fedora sets up ALSA dmix by default (or one of the packages I installed did) I imagine the answer is no. If I can check this somehow (and it is relevant for me to check that) let me know.

smcv commented 3 years ago

I do know what ALSA is, but I should be using PulseAudio

OK, good. That's what I expected for a Fedora user, but it's good to be sure!

I think this indicates that either we are not passing PulseAudio through to the container correctly, or there is some game-specific bug in Shadowrun Returns that means it doesn't see the PulseAudio socket (or something).

Would you mind capturing a new log with environment variable STEAM_LINUX_RUNTIME_VERBOSE=1 set?

Should I still do this seeing as RyuzakiKK is on it?

More information is usually better than less information, so if you have a chance, a log would probably still be useful.

I don't know whether the symptoms you're experiencing are actually anything to do with the issue @RyuzakiKK can reproduce - it just seemed like something in your system info that shouldn't be there.

Newbytee commented 3 years ago

Would you mind capturing a new log with environment variable STEAM_LINUX_RUNTIME_VERBOSE=1 set?

Should both STEAM_LINUX_RUNTIME_VERBOSE=1 and STEAM_LINUX_RUNTIME_LOG=1 be set, or should only the first one (verbose) be set?

smcv commented 3 years ago

Should both STEAM_LINUX_RUNTIME_VERBOSE=1 and STEAM_LINUX_RUNTIME_LOG=1 be set?

Both is usually easier. If you set both, you get slr-*.log as before. If you only set _VERBOSE, the output goes to wherever Steam is sending its stderr.

Newbytee commented 3 years ago

Would you mind capturing a new log with environment variable STEAM_LINUX_RUNTIME_VERBOSE=1 set?

Here you go: slr-app234650-t20210310T174303.log

smcv commented 3 years ago

Regarding the audio, what is meant to happen is that we mount your PulseAudio socket into the container, and set the PULSE_SERVER environment variable to point to it. From your latest log, it looks like we're doing this correctly:

17:43:04.464863: pressure-vessel-wrap[26962]: D: Locking environment variable: PULSE_CLIENTCONFIG
17:43:04.464878: pressure-vessel-wrap[26962]: D: Locking environment variable: PULSE_SERVER
...
17:43:04.480857: pressure-vessel-wrap[26962]: D:    '--ro-bind-data'
17:43:04.480872: pressure-vessel-wrap[26962]: D:    '17'
17:43:04.480886: pressure-vessel-wrap[26962]: D:    '/run/user/1000/pulse/config'
17:43:04.480899: pressure-vessel-wrap[26962]: D:    '--ro-bind'
17:43:04.480913: pressure-vessel-wrap[26962]: D:    '/run/user/1000/pulse/native'
17:43:04.480928: pressure-vessel-wrap[26962]: D:    '/run/user/1000/pulse/native'
...
17:43:04.483026: pressure-vessel-wrap[26962]: D:    'PULSE_CLIENTCONFIG=/run/user/1000/pulse/config'
17:43:04.483040: pressure-vessel-wrap[26962]: D:    'PULSE_SERVER=unix:/run/user/1000/pulse/native'

However, whatever audio library is used in Shadowrun Returns (FMOD?) doesn't seem to be picking that up, and instead it falls back to ALSA.

We do have libasound_module_pcm_pulse.so and libasound_module_ctl_pulse.so included in the runtime, so I would expect this to work - but perhaps they're too old to operate with your PulseAudio server? Or perhaps we need to install configuration in the container to make PulseAudio the default if present.

smcv commented 3 years ago

I'm sure your PulseAudio version is fine, it's the one in the runtime that might not be!

smcv commented 3 years ago

perhaps we need to install configuration in the container to make PulseAudio the default if present

In the scout runtime's files/share/alsa/alsa.conf.d/ (from your log, I think that would mean /mnt/storage/SteamLibrary/steamapps/common/SteamLinuxRuntime/var/deploy-0.20210309.0/files/share/alsa/alsa.conf.d/), please try renaming 99-pulseaudio-default.conf.example to 99-pulseaudio-default.conf?

If that workaround works, then we can make pressure-vessel do something similar itself.

kisak-valve commented 3 years ago

Renaming that config file gets audio working in the main menu with AudioManager: Using ALSA: default in the engine log, and doesn't affect the quit button.

Not the ideal direct connection to Pulseaudio like outside Steam Linux Runtime, but better than failing.

ADDITION: And now I'm confused, the game continued to have working audio with alsa after I renamed the config file back to the original name.

smcv commented 3 years ago

Not the ideal direct connection to Pulseaudio

I don't think the result of renaming that config file is any less direct than what we would be doing on the host system, actually. Either way, the path is going to look like this:

the game -> libasound.so.2 -> libasound_module_pcm_pulse.so -> libpulse.so.0 -> (IPC) -> pulseaudio

On the host system (or at least on my Debian testing/unstable system) there's a config file that probes to see whether PulseAudio is actually available, and if yes, makes it the default libasound.so.2 plugin - but the scout container is too old to have that.

And now I'm confused, the game continued to have working audio with alsa after I renamed the config file back to the original name.

Weird. Maybe it remembered which device it was using last time?

kisak-valve commented 3 years ago

For clarity, the engine log (output.txt) has AudioManager: Using PulseAudio: Default Output Device when run outside the Steam Linux Runtime container on my system, and now AudioManager: Using ALSA: default inside the container. Yesterday when I tested, I got FMOD failed to initialize ... Error initializing output device. inside the container. By direct connection I only meant that the audio subsystem knew it was talking directly to PulseAudio instead of an ALSA component.

Newbytee commented 3 years ago

I'm sure your PulseAudio version is fine, it's the one in the runtime that might not be!

Yes, I deleted my comment once I realised I had misread. Should probably just have edited it.

perhaps we need to install configuration in the container to make PulseAudio the default if present

In the scout runtime's files/share/alsa/alsa.conf.d/ (from your log, I think that would mean /mnt/storage/SteamLibrary/steamapps/common/SteamLinuxRuntime/var/deploy-0.20210309.0/files/share/alsa/alsa.conf.d/), please try renaming 99-pulseaudio-default.conf.example to 99-pulseaudio-default.conf?

If that workaround works, then we can make pressure-vessel do something similar itself.

I can confirm this makes the main menu audio play for me.

ADDITION: And now I'm confused, the game continued to have working audio with alsa after I renamed the config file back to the original name.

Peculiar. Not the case here. (audio is gone again after I moved it back)

smcv commented 3 years ago

I tried running the game in a SDK container instead of the default Platform container, and running it through strace (which is available in the SDK), to get more information out of it.

Sound

It looks as though this game engine checks for the presence of a working PulseAudio by running the shell command pulseaudio --check > /dev/null 2>&1 - which isn't going to work as-is inside the container, because the container only has the PulseAudio client library, not the PulseAudio daemon.

I think that's why @kisak-valve gets different logging inside and outside the container. Outside the container, that shell command succeeds, and FMOD selects its built-in PulseAudio backend. Inside the container and with PulseAudio set as default in alsa.conf.d, FMOD falls back to its ALSA backend, which uses libasound (the ALSA user-space library), which outputs via PulseAudio. Inside the container but without setting PulseAudio as the default, libasound defaults to dmix, which can't cross the container boundary and fails.

So I think we have two possible feature requests for pressure-vessel here:

Exiting

Exiting works if I run it in the SDK environment! However, the way this particular game exits is weird: instead of doing something ordinary like exit(0) or even raise(SIGTERM), it kills itself with SIGKILL. This seems a bizarre thing to do, but is apparently a somewhat common workaround used in Unity games to avoid crashes caused by bugs in code that would otherwise run during a clean shutdown?

In the Platform environment, I can reproduce the bug with it not exiting. In a strace log, I can see it trying to access /proc/0, so maybe it has got confused about what its own process ID is?

Other bugs

It looks like this game also assumes that /usr/bin/lsb_release exists, and will log crash reports (but still work?!) if it doesn't.

smcv commented 3 years ago
  • if PulseAudio is available, set libasound's PulseAudio module as the default
  • if PulseAudio is available, put a stub pulseaudio executable in the PATH

These are both implemented and should be in the next beta, versioned >= 0.20210317.0; check for pressure-vessel 0.20210317.0+srt1 or later in SteamLinuxRuntime/VERSIONS.txt if you are not sure whether you have this version. [edited to add: This was released on 2021-03-19.]

  • Game doesn't exit when the in-game quit button is pressed (but exiting it via my window manager works fine)

This is not resolved, unless some other change accidentally fixes it.

  • It looks like this game also assumes that /usr/bin/lsb_release exists, and will log crash reports (but still work?!) if it doesn't

This is not resolved either, although I'm tempted to add a lsb_release in a future version of the runtime.

Techwolf commented 2 years ago

" libasound defaults to dmix, which can't cross the container boundary and fails."

Is this why I can not get Proton to use ALSA:Device:Plug:dmix? Everything I have tried so far fails and it always goes to ALSA:Device:HW:0.0, blocking all chat programs, like discord, teamspeak, etc. from working. Is there any way to get Proton to actually use ALSA:Device:Plug:dmix? I do have ALSA:default pointing to plug:dmix.

Newbytee commented 2 years ago

Unfortunately it seems like this game has regressed :(. When I launch it with Pressure Vessel now, it only loads to a black screen. Eventually the music comes on, but the menu never seems to appear. It also launches much slower than when running outside of Pressure Vessel. (So, to be clear, it works just fine if I disable "Steam Linux Runtime" and run it without a compatibility tool)

Here's the log: slr-app234650-t20220331T170301.log And here is the versions file: VERSIONS.txt

smcv commented 2 years ago

@Techwolf: Please don't jump onto someone else's issue report to ask questions or report issues that don't match the topic of the original issue report. If we let one issue number grow to cover multiple topics, it becomes increasingly difficult to keep track of which parts are fixed and which parts are not.

But in answer to your question: #501.

smcv commented 2 years ago

@Newbytee, I see Shadowrun Returns has a -logFile output.txt parameter. Is anything useful or interesting logged in that file?

Newbytee commented 2 years ago

Actually, sorry. False flag. This only happens if I run the game in GNOME Wayland with the proprietary NVIDIA driver. If I switch to X.Org, it works the same as before (everything but the exit button works fine). I was using X.Org last time I tested this, so it's probably not a regression. I would wager it's probably some EGLStream-exclusive issue (not using GBM yet), so personally I wouldn't mind forgetting about it unless you still want to look into it. Notably, it also happens if I launch the game using Flatpak Steam from Flathub, even if no compatibility tool is selected.

smcv commented 2 years ago

This only happens if I run the game in GNOME Wayland with the proprietary NVIDIA driver

Coincidentally, I've been testing that situation recently myself, and my conclusion was that even though the 510.x driver is meant to be able to do native Wayland, not enough stars have aligned to make it actually reliable yet.