Steam Big Picture mode instantly Crashes on OpenSuSE Leap 15.4

[dralanmage]

Your system information

• Steam client version (build number or date): Jun 7 2022, at 03:18:43
• Distribution (e.g. Ubuntu): OpenSuSE Leap 15.4
• Opted into Steam client beta?: [Yes/No] No
• Have you checked for system updates?: [Yes/No] Yes

Please describe your issue in as much detail as possible:

Describe what you expected should happen and what did happen. Please link any large code pastes as a Github Gist

My video card is an AMD RX 6700XT, and I am using the kernel drivers from my distro.

I expected to go into big picture mode. Instead, nothing happened. After running steam from a console, I saw that a crash happened and a dump was generated, but I'm not sure how to inspect the dump (I wasn't able to open it with gdb). I confirmed that at least one other person has the exact same issue I have, and it is reproducible 100% of the time.

https://www.reddit.com/r/openSUSE/comments/w39kmn/steam_big_picture_mode_opensuse_leap_154_crash/

Installing breakpad exception handler for appid(steam)/version(1654574690)
crash_20220720172222_32.dmp[13116]: Uploading dump (out-of-process)
/tmp/dumps/crash_20220720172222_32.dmp
/home/dralan/.local/share/Steam/steam.sh: line 794: 12234 Illegal instruction (core dumped) "$STEAMROOT/$STEAMEXEPATH" "$@"

crash_20220720172222_32.dmp[13116]: Finished uploading minidump (out-of-process): success = yes
crash_20220720172222_32.dmp[13116]: response: CrashID=bp-6fbb27d2-111c-4c90-b2de-754f72220720
crash_20220720172222_32.dmp[13116]: file ''/tmp/dumps/crash_20220720172222_32.dmp'', upload yes: ''CrashID=bp-6fbb27d2-111c-4c90-b2de-754f72220720''

Steps for reproducing this issue:

1. Launch Steam
2. Enter Big Picture Mode
3. Crash

[kisak-valve]

Hello @dralanmage, blind guess, can you completely close Steam, then try running steam -bigpicture -no-cef-sandbox from a terminal and see if that has an effect?

If that doesn't help, then please start Steam in desktop mode, copy your system information from Steam (Steam -> Help -> System Information) and put it in a gist, then include a link to the gist in this issue report.

[dralanmage]

Hello @kisak-valve, that also results in a crash:

crash_20220720181027_21.dmp[26211]: Uploading dump (out-of-process)
/tmp/dumps/crash_20220720181027_21.dmp
/home/dralan/.local/share/Steam/steam.sh: line 794: 25900 Illegal instruction (core dumped) "$STEAMROOT/$STEAMEXEPATH" "$@"
crash_20220720181027_21.dmp[26211]: Finished uploading minidump (out-of-process): success = yes0:27 PM 
crash_20220720181027_21.dmp[26211]: response: CrashID=bp-8d9d5b28-0981-4321-9612-b30ec2220720
crash_20220720181027_21.dmp[26211]: file ''/tmp/dumps/crash_20220720181027_21.dmp'', upload yes: ''CrashID=bp-8d9d5b28-0981-4321-9612-b30ec2220720''

[dralanmage]

@kisak-valve, does this work?

https://gist.github.com/dralanmage/39f55530c5fab522923529819e144359

[veloc1]

Same here. And steam also crashing, when opening "controller settings". IIRC, there is same looking window, as in Big Picture?

Steam client version (build number or date): Jul 19 2022, at 20:51:26
Distribution (e.g. Ubuntu): Fedora Rawhide
Opted into Steam client beta?: [Yes/No] Yes
Have you checked for system updates?: [Yes/No] Yes

GPU is Radeon 6600XT.

Debugging with gdb points to steamui.so.

Latest log record: SDL_CreateWindow failedFailed creating tenfoot window. Also, there is SDL related record at startup Couldn't initialize SDL: wayland not available. Crash occurs both on Wayland and X11.

[karli-sjoberg]

Same here, but FYI, it happened on Leap 15.3 as well, plus I'm using NVIDIA GPU, so it's not tied to either. I opened a case through Steam but was told to come here. For reference, the case ID is "HT-NP5X-WC4W-KD9F"

[karli-sjoberg]

Also:
https://gist.github.com/karli-sjoberg/b5d781b601b085b02eff1f014fbf27ee

[dralanmage]

I'd like to add that big picture mode was working for me on Leap 15.3, but I was using the kernel backports repo and had a much more recent kernel. My hardware was the same.

[dralanmage]

I also tried switching to the Steam beta, which has the same issue.

[dralanmage]

I couldn't figure out how to debug the mini dump file generate by steam, or how to start steam with gdb (this looks very complex), but I was able to attach gdb to the steam pid after it started up, and nabbed this backtrace:

Thread 1 "steam" received signal SIGILL, Illegal instruction.
0xf7fa6217 in _dl_map_object_from_fd () from /lib/ld-linux.so.2
(gdb) bt
#0 0xf7fa6217 in _dl_map_object_from_fd () from /lib/ld-linux.so.2
#1 0xf7fa81f0 in _dl_map_object () from /lib/ld-linux.so.2
#2 0xf7fad634 in openaux () from /lib/ld-linux.so.2
#3 0xf7a51d42 in _dl_catch_exception () from /lib/libc.so.6
#4 0xf7fad950 in _dl_map_object_deps () from /lib/ld-linux.so.2
#5 0xf7fb35d0 in dl_open_worker () from /lib/ld-linux.so.2
#6 0xf7a51d42 in _dl_catch_exception () from /lib/libc.so.6
#7 0xf7fb30ee in _dl_open () from /lib/ld-linux.so.2
#8 0xf7f92e75 in dlopen_doit () from /lib/libdl.so.2
#9 0xf7a51d42 in _dl_catch_exception () from /lib/libc.so.6
#10 0xf7a51de0 in _dl_catch_error () from /lib/libc.so.6
#11 0xf7f93621 in _dlerror_run () from /lib/libdl.so.2
#12 0xf7f92f38 in dlopen@@GLIBC_2.1 () from /lib/libdl.so.2
#13 0x566704d3 in __wrap_dlopen ()
#14 0xb1456688 in ?? () from /home/dralan/.local/share/Steam/ubuntu12_32/panorama/panorama.so
#15 0xb1458881 in ?? () from /home/dralan/.local/share/Steam/ubuntu12_32/panorama/panorama.so
#16 0xb145ba44 in ?? () from /home/dralan/.local/share/Steam/ubuntu12_32/panorama/panorama.so
#17 0xb146cf6e in CreatePanoramaUIEngineInternal () from /home/dralan/.local/share/Steam/ubuntu12_32/panorama/panorama.so
#18 0xd7686c6e in ?? () from /home/dralan/.local/share/Steam/ubuntu12_32/steamui.so
#19 0xd6dbadee in ?? () from /home/dralan/.local/share/Steam/ubuntu12_32/steamui.so
#20 0xd6e75e1c in ?? () from /home/dralan/.local/share/Steam/ubuntu12_32/steamui.so
#21 0xd6e668ef in ?? () from /home/dralan/.local/share/Steam/ubuntu12_32/steamui.so
#22 0xd6e6909b in ?? () from /home/dralan/.local/share/Steam/ubuntu12_32/steamui.so
#23 0xd77b4f55 in ?? () from /home/dralan/.local/share/Steam/ubuntu12_32/steamui.so

[dralanmage]

A bunch of updates came in today on Leap 15.4 and now, using the same version of steam, big picture mode works!

[karli-sjoberg]

No updates for Leap installed yet, but after a Steam client update, Big Picture works again.

[tajnymag]

Does happen on Arch Linux too

[Zrocket]

I can confirm that this is also happening on Manjaro.

[TTimo]

CNR on Manjaro - please provide newly uploaded crash IDs maybe (the ones above have been purged from our servers already).

[Zrocket]

CNR on Manjaro - please provide newly uploaded crash IDs maybe (the ones above have been purged from our servers already).

CrashID=bp-e1e5f0ce-7c60-4902-b5e7-dd8532220919

I've tried seeking help on Manjaro's support forum, but without luck. I can't tell if problem exists on my end or Steam's. As such, i'd honestly just be happy to know what's happening.

[TTimo]

CrashID=bp-e1e5f0ce-7c60-4902-b5e7-dd8532220919

This is a pretty different crash than the stack trace in #8695 (comment)

This one happens right as the panorama.so module is being loaded. Unfortunately it doesn't point at any obvious code, looks like it might be very host specific.

[Zrocket]

CrashID=bp-e1e5f0ce-7c60-4902-b5e7-dd8532220919

This is a pretty different crash than the stack trace in #8695 (comment)

This one happens right as the panorama.so module is being loaded. Unfortunately it doesn't point at any obvious code, looks like it might be very host specific.

Thank you. Anything I can do to try to diagnose this further? I've been trying to solve this myself, but I haven't had any leads until now. While I'm able to use the unofficial flatpak, I'd love to be able to get the host steam-runtime to work again.

[TTimo]

You could try removing/disabling pulseaudio. Somehow it's in the stack trace (which might be just be due to some bugs in the crash info collection). I can't repro here and I'm use pipewire. Time permitting I'll ponder on this some more.

[Zrocket]

You could try removing/disabling pulseaudio. Somehow it's in the stack trace (which might be just be due to some bugs in the crash info collection). I can't repro here and I'm use pipewire. Time permitting I'll ponder on this some more.

Strange, I also use pipewire.

[Zrocket]

Nevermind, I figured it out. It was something to do with pipewire-pulse. Still not sure why, but reinstalling it seems to have worked.

[VortexAcherontic]

Big Picture Crashes also on openSUSE MicroOS via flatpak:

src/panorama/text/uitextlayoutpango.cpp (344) : Fatal Assertion Failed: Unable to load 'libpangoft2-1.0.so' (error info 'libpango-1.0.so: cannot enable executable stack as shared object requires: Permission denied'), your game install may be corrupted or you may have a system conflict

src/panorama/text/uitextlayoutpango.cpp (344) : Fatal Assertion Failed: Unable to load 'libpangoft2-1.0.so' (error info 'libpango-1.0.so: cannot enable executable stack as shared object requires: Permission denied'), your game install may be corrupted or you may have a system conflict

src/panorama/text/uitextlayoutpango.cpp (344) : Fatal assert; application exiting
src/panorama/text/uitextlayoutpango.cpp (344) : Fatal assert; application exiting
Installing breakpad exception handler for appid(steam)/version(1666144119)
assert_20221114183122_30.dmp[666]: Uploading dump (out-of-process)
/tmp/dumps/assert_20221114183122_30.dmp
_ExitOnFatalAssert
assert_20221114183122_30.dmp[666]: Finished uploading minidump (out-of-process): success = yes
assert_20221114183122_30.dmp[666]: response: CrashID=bp-dcb51f4c-e7cc-48c1-8c07-b44542221114
assert_20221114183122_30.dmp[666]: file ''/tmp/dumps/assert_20221114183122_30.dmp'', upload yes: ''CrashID=bp-dcb51f4c-e7cc-48c1-8c07-b44542221114''

[Hunter-Phipps]

Same issue on the latest version of OpenSUSE Tumbleweed.

[TTimo]

Hello,

Please provide up to date uploaded CrashID numbers and system reports (https://github.com/ValveSoftware/steam-for-linux/#system-information), thanks!

[VortexAcherontic]

Same issue on the latest version of OpenSUSE MicroOS

Do you run it from flathub or did you use the native package? Just counter tested it on my MicroOS to provide up-to-date logs and it works now.

[VortexAcherontic]

Replying to #8695 (comment)

Looks like SELinux, try the following and see if that helps:

sudo setsebool -P selinuxuser_execstack 1
And then start big picture again.
If this solves the issues someone at Valve should look into libpango and if it is possible to somehow not execute commands on the stack.

SELinux doc:

If you want to allow unconfined executables to make their stack executable. This should never, ever be necessary. Probably indicates a badly coded executable, but could indicate an attack. This executable should be reported in bugzilla, you must turn on the selinuxuser_execstack boolean. Enabled by default.

[lucasreis1]

Can confirm this is happening on Arch too

[smcv]

I think what is happening here is:

In very old Linux, all executables and libraries were technically able to execute code from the stack. For instance, if you have some sort of JIT or "trampoline" going on, it could potentially generate temporary x86 code in a buffer on the stack and then jump to it.

In modern Linux, this is frowned upon, because it increases security risk and isn't usually particularly useful. The toolchain can't just forbid it altogether, because that would potentially break backwards-compatibility with old executables and libraries, so it's opt-in: each executable or library can (and should) contain a marker (in the PT_GNU_STACK header) which means "I promise I won't use executable code on the stack", which will make the runtime dynamic linker set up permissions to make that impossible. If that marking isn't there, the runtime dynamic linker will usually go into a backwards-compatible mode where it sets up different permissions that behave like old Linux, which is less secure but more compatible.

However, in SELinux, because SELinux is a mechanism for sacrificing some functionality for security, the default is that executables and libraries are not allowed to load unless they have a PT_GNU_STACK header declaring them to not need an executable stack. sudo setsebool -P selinuxuser_execstack 1 turns off this behaviour, which, again, is less secure but more compatible.

You can see the marker in readelf -a output, under Program Headers -> GNU_STACK, or in objdump -x output, under Program Header -> STACK. If the flags are set to RW or rw- (like they are for ~/.steam/root/ubuntu12_32/steamclient.so for example), then that's good. If they are set to RWE or rwx (like for ~/.steam/root/ubuntu12_32/panorama/libpango-1.0.so for example), then that's bad. If the PT_GNU_STACK header is missing completely, that's also bad. Ideally, all ELF executable code that's installed by Steam (executables, shared libraries and plugins) should have a PT_GNU_STACK header that flags it as not needing this backwards compatibility.

If panorama/libpango-1.0.so has been compiled with a halfway modern compiler, it should automatically get flagged with or without an executable stack according to whether gcc thinks it needs one. There are three common reasons to get an executable stack:

1. The executable/library uses certain gcc extensions that need "trampolines" on an executable stack, notably nested functions
2. The executable/library contains assembly language code (a .S file in the source code), and gcc pessimistically assumes that it might need an executable stack
3. The executable/library contains inline assembly in a C or C++ source file (the gcc __asm__ extension), and gcc pessimistically assumes that it might need an executable stack

For (1), the solution is to convert nested functions into normal non-nested C functions.

For (2), assuming the assembly code is not actually generating new x86 code on the stack, the Ubuntu and Gentoo wiki pages linked below have some runes that can be used.

For (3), I think there's a mechanism that can be used similar to (2), but I don't immediately know it.

More info: https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks, https://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart

[smcv]

If it's possible to make Steam use the Steam Runtime's Pango (the same one used for games) instead of carrying its own copy, then that would resolve this easily: the Steam Runtime's Pango doesn't have the executable stack marker, and the OS's 32-bit Pango (if installed) almost certainly doesn't either.

[smcv]

3. The executable/library contains inline assembly in a C or C++ source file (the gcc asm extension), and gcc pessimistically assumes that it might need an executable stack

Correction: it looks like gcc assumes that inline assembly does not need an executable stack, so probably (3) is not a problem, and instead it's (1) or (2) happening here. It's probably the statically linked libffi in panorama/libpango-1.0.so that is causing this, rather than Pango itself.

[smcv]

If I understand correctly, panorama/ is only for the old Big Picture mode (the very blue one), and not "new Big Picture" (basically the Steam Deck UI, also available on desktop in the Steam beta branch). If the Steam-Deck-style UI is intended to eventually replace the old blue Big Picture completely, then this problem will disappear when the old blue Big Picture does.

[VortexAcherontic]

If I understand correctly, panorama/ is only for the old Big Picture mode (the very blue one), and not "new Big Picture" (basically the Steam Deck UI, also available on desktop in the Steam beta branch). If the Steam-Deck-style UI is intended to eventually replace the old blue Big Picture completely, then this problem will disappear when the old blue Big Picture does.

Yes. As the Steam Deck UI runs fine on my system, except for it's very own set of bugs. I guess this one will never be fixed as it simply wouldn't be worth the time.