Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Games open in an invisible window since 3.14.3 when using FSR #1237

Open
zany130 opened this issue Apr 11, 2024 · 21 comments
Open

Games open in an invisible window since 3.14.3 when using FSR #1237

zany130 opened this issue Apr 11, 2024 · 21 comments

Comments

@zany130
Copy link

zany130 commented Apr 11, 2024

when I run Steam inside Gamescope (still nested under KDE in order to work around #1180)

any game I launch launches in an invisible window

this is ever since updating to the latest tag release https://github.com/ValveSoftware/gamescope/releases/tag/3.14.3

I have tried the following games:

a hat in time

Persona 3 Reload

Trails into reverie

Yooka-Layle (native linux game)

gamescope also seems to crash when trying to open the steam overlay or alt tab

EDIT:removing FSR from the gamescop arguments fixes the issue

possibly related to #1111 even though it was fixed for me for a while (ie: works on 3.14.2 #1005) ( I always use fsr when using gamescope)

Gamescope output
gamescope -w 2560 -h 1440 -W 3840 -H 2160 -r 120 -o 30 -f -e -F fsr -S auto --fsr-sharpness 2 --immediate-flips --adaptive-sync --rt -- steam-runtime
No CAP_SYS_NICE, falling back to regular-priority compute and threads.
Performance will be affected.
ATTENTION: default value of option vk_khr_present_wait overridden by environment.
ATTENTION: default value of option vk_khr_present_wait overridden by environment.
vulkan: selecting physical device 'AMD Radeon RX 6700 XT (RADV NAVI22)': queue family 1 (general queue family 0)
vulkan: physical device supports DRM format modifiers
wlserver: [backend/headless/backend.c:67] Creating headless backend
xdg_backend: Seat name:
vulkan: supported DRM formats for sampling usage:
vulkan:   AR24 (0x34325241)
vulkan:   XR24 (0x34325258)
vulkan:   AB24 (0x34324241)
vulkan:   XB24 (0x34324258)
vulkan:   RG16 (0x36314752)
vulkan:   NV12 (0x3231564E)
vulkan:   AB4H (0x48344241)
vulkan:   XB4H (0x48344258)
vulkan:   AB48 (0x38344241)
vulkan:   XB48 (0x38344258)
vulkan:   AB30 (0x30334241)
vulkan:   XB30 (0x30334258)
vulkan:   AR30 (0x30335241)
vulkan:   XR30 (0x30335258)
wlserver: Running compositor on wayland display 'gamescope-0'
wlserver: [backend/headless/backend.c:17] Starting headless backend
wlserver: [xwayland/server.c:107] Starting Xwayland on :1
wlserver: [types/wlr_compositor.c:771] New wlr_surface 0x5da5716f3ea0 (res 0x5da5716f3500)
wlserver: [xwayland/server.c:272] Xserver is ready
pipewire: stream state changed: connecting
pipewire: stream state changed: paused
pipewire: stream available on node ID: 79
xwm: Embedded, no cursor set. Using left_ptr by default.
vblank: Using timerfd.
xdg_backend: PreferredMetadata: Red: 0.64 0.33, Green: 0.3 0.6, Blue: 0.15 0.06, White: 0.3127 0.329, Max Luminance: 100 nits, Min Luminance: 0 nits, Max Full Frame Luminance: 100 nits
josh edid: Patching res 800x1280 -> 2560x1440
pipewire: renegotiating stream params (size: 3839x2158)
steam.sh[122713]: Running Steam on garuda Soaring 64-bit
steam.sh[122713]: STEAM_RUNTIME is enabled automatically
setup.sh[122783]: Steam runtime environment up-to-date!
steam.sh[122713]: Steam client's requirements are satisfied
tid(122839) burning pthread_key_t == 0 so we never use it
[2024-04-11 17:00:35] Startup - updater built Mar  6 2024 20:27:25
[2024-04-11 17:00:35] Startup - Steam Client launched with: '/home/zany130/.local/share/Steam/ubuntu12_32/steam'
minidumps folder is set to /tmp/dumps
04/11 17:00:35 Init: Installing breakpad exception handler for appid(steam)/version(1709846872)/tid(122839)
[2024-04-11 17:00:35] Loading cached metrics from disk (/home/zany130/.local/share/Steam/package/steam_client_metrics.bin)
[2024-04-11 17:00:35] Using the following download hosts for Public, Realm steamglobal
[2024-04-11 17:00:35] 1. https://client-update.akamai.steamstatic.com, /, Realm 'steamglobal', weight was 1000, source = 'update_hosts_cached.vdf'
[2024-04-11 17:00:35] 2. https://cdn.cloudflare.steamstatic.com, /client/, Realm 'steamglobal', weight was 1, source = 'update_hosts_cached.vdf'
[2024-04-11 17:00:35] 3. https://cdn.steamstatic.com, /client/, Realm 'steamglobal', weight was 1, source = 'baked in'
[2024-04-11 17:00:35] Verifying installation...
[2024-04-11 17:00:35] Verification complete
wlserver: [types/wlr_compositor.c:771] New wlr_surface 0x5da571499b30 (res 0x5da5716f6200)
xwm: got the same buffer committed twice, ignoring.
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Unsupported maximum keycode 708, clipping.
>                   X11 cannot support keycodes above 255.
> Warning:          Could not resolve keysym XF86KbdInputAssistPrevgrou
> Warning:          Could not resolve keysym XF86KbdInputAssistNextgrou
Errors from xkbcomp are not fatal to the X server
pipewire: renegotiating stream params (size: 3839x2156)
xwm: error 3: BadWindow (invalid Window parameter) request 15 minor 0 serial 332
UpdateUI: showing logo
Steam logging initialized: directory: /home/zany130/.local/share/Steam/logs

XRRGetOutputInfo Workaround: initialized with override: 1 real: 0xda177dc0
XRRGetCrtcInfo Workaround: initialized with override: 1 real: 0xda176500
steamwebhelper.sh[123150]: === Thu Apr 11 05:00:38 PM EDT 2024 ===
steamwebhelper.sh[123150]: Starting steamwebhelper under bootstrap sniper steam runtime at /home/zany130/.local/share/Steam/ubuntu12_64/steam-runtime-sniper
CAppInfoCacheReadFromDiskThread took 64 milliseconds to initialize
Steam Runtime Launch Service: starting steam-runtime-launcher-service
Steam Runtime Launch Service: steam-runtime-launcher-service is running pid 123365
bus_name=com.steampowered.PressureVessel.LaunchAlongsideSteam
pipewire: renegotiating stream params (size: 1745x980)
pipewire: renegotiating stream params (size: 3839x2158)
ATTENTION: default value of option vk_khr_present_wait overridden by environment.
ATTENTION: default value of option vk_khr_present_wait overridden by environment.
[Gamescope WSI] Forcing on VK_EXT_swapchain_maintenance1.
ATTENTION: default value of option vk_khr_present_wait overridden by environment.
ATTENTION: default value of option vk_khr_present_wait overridden by environment.
/usr/share/themes/Sweet-Dark/gtk-2.0/main.rc:727: error: unexpected identifier 'direction', expected character '}'
/usr/share/themes/Sweet-Dark/gtk-2.0/apps/chrome.rc:50: error: invalid string constant "button", expected valid string constant
/usr/share/themes/Sweet-Dark/gtk-2.0/apps/xfce.rc:79: error: invalid string constant "entry", expected valid string constant
wlserver: [types/wlr_compositor.c:771] New wlr_surface 0x5da571811c00 (res 0x5da5716489c0)
xwm: Unhandled NET_WM_STATE property change: _NET_WM_STATE_MAXIMIZED_VERT
xwm: Unhandled NET_WM_STATE property change: _NET_WM_STATE_MAXIMIZED_HORZ
pipewire: renegotiating stream params (size: 3839x2156)
BRefreshApplicationsInLibrary 1: 19ms
CDesktopCapturePipeWire: Opening DRM render node /dev/dri/renderD128
CDesktopCapturePipeWire: setting stream node ID: 79
BuildCompleteAppOverviewChange: 514 apps
RegisterForAppOverview 1: 22ms
RegisterForAppOverview 2: 22ms
/bin/sh\0-c\0/home/zany130/.local/share/Steam/ubuntu12_32/reaper SteamLaunch AppId=360830 -- /home/zany130/.local/share/Steam/ubuntu12_32/steam-launch-wrapper -- '/mnt/GAMES/SteamLibrary/steamapps/common/YookaLaylee/YookaLaylee.x86_64'\0
chdir "/mnt/GAMES/SteamLibrary/steamapps/common/YookaLaylee"
ERROR: ld.so: object '/home/zany130/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/zany130/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
ERROR: ld.so: object '/home/zany130/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/zany130/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
Found path: /mnt/GAMES/SteamLibrary/steamapps/common/YookaLaylee/YookaLaylee.x86_64
Mono path[0] = '/mnt/GAMES/SteamLibrary/steamapps/common/YookaLaylee/YookaLaylee_Data/Managed'
Mono path[1] = '/mnt/GAMES/SteamLibrary/steamapps/common/YookaLaylee/YookaLaylee_Data/Mono'
Mono config path = '/mnt/GAMES/SteamLibrary/steamapps/common/YookaLaylee/YookaLaylee_Data/Mono/etc'
displaymanager : xrandr version warning. 1.6
displaymanager : trying .X11-unix
client :0 has 1 screens
displaymanager screen (0): 13695 x 3949
client :1 has 1 screens
displaymanager screen (1): 2560 x 1440
Using libudev for joystick management


Importing game controller configs
Found /dev/input/event256
Mapping raw axis 0 to 0
Mapping raw axis 1 to 1
Mapping raw axis 2 to 2
Mapping raw axis 3 to 3
Mapping raw axis 4 to 4
Mapping raw axis 5 to 5
input-remapper DualSense Wireless Controller forwarded: Mapping b0.0 to b0
input-remapper DualSense Wireless Controller forwarded: Mapping b1.0 to b1
input-remapper DualSense Wireless Controller forwarded: Mapping b8.0 to b6
input-remapper DualSense Wireless Controller forwarded: Mapping h0.4 to a7
input-remapper DualSense Wireless Controller forwarded: Mapping h0.8 to a6
input-remapper DualSense Wireless Controller forwarded: Mapping h0.2 to a6
input-remapper DualSense Wireless Controller forwarded: Mapping h0.1 to a7
input-remapper DualSense Wireless Controller forwarded: Mapping b10.0 to b8
input-remapper DualSense Wireless Controller forwarded: Mapping b4.0 to b4
input-remapper DualSense Wireless Controller forwarded: Mapping b11.0 to b9
input-remapper DualSense Wireless Controller forwarded: Mapping a2.0 to a2
input-remapper DualSense Wireless Controller forwarded: Mapping a0.0 to a0
input-remapper DualSense Wireless Controller forwarded: Mapping a1.0 to a1
input-remapper DualSense Wireless Controller forwarded: Mapping b5.0 to b5
input-remapper DualSense Wireless Controller forwarded: Mapping b12.0 to b10
input-remapper DualSense Wireless Controller forwarded: Mapping a5.0 to a5
input-remapper DualSense Wireless Controller forwarded: Mapping a3.0 to a3
input-remapper DualSense Wireless Controller forwarded: Mapping a4.0 to a4
input-remapper DualSense Wireless Controller forwarded: Mapping b9.0 to b7
input-remapper DualSense Wireless Controller forwarded: Mapping b3.0 to b2
input-remapper DualSense Wireless Controller forwarded: Mapping b2.0 to b3
Unknown mapping for 'platform': skipping
Assigning joystick 1
Found /dev/input/event26
Mapping raw axis 0 to 0
Mapping raw axis 1 to 1
Mapping raw axis 2 to 2
Mapping raw axis 3 to 3
Mapping raw axis 4 to 4
Mapping raw axis 5 to 5
DualSense Wireless Controller: Mapping b0.0 to b0
DualSense Wireless Controller: Mapping b1.0 to b1
DualSense Wireless Controller: Mapping b8.0 to b6
DualSense Wireless Controller: Mapping h0.4 to a7
DualSense Wireless Controller: Mapping h0.8 to a6
DualSense Wireless Controller: Mapping h0.2 to a6
DualSense Wireless Controller: Mapping h0.1 to a7
DualSense Wireless Controller: Mapping b10.0 to b8
DualSense Wireless Controller: Mapping b4.0 to b4
DualSense Wireless Controller: Mapping b11.0 to b9
DualSense Wireless Controller: Mapping a2.0 to a2
DualSense Wireless Controller: Mapping a0.0 to a0
DualSense Wireless Controller: Mapping a1.0 to a1
DualSense Wireless Controller: Mapping b5.0 to b5
DualSense Wireless Controller: Mapping b12.0 to b10
DualSense Wireless Controller: Mapping a5.0 to a5
DualSense Wireless Controller: Mapping a3.0 to a3
DualSense Wireless Controller: Mapping a4.0 to a4
DualSense Wireless Controller: Mapping b9.0 to b7
DualSense Wireless Controller: Mapping b3.0 to b2
DualSense Wireless Controller: Mapping b2.0 to b3
Unknown mapping for 'platform': skipping
Assigning joystick 2
wlserver: [types/wlr_compositor.c:771] New wlr_surface 0x5da57181e590 (res 0x5da5716ae860)
xwm: got the same buffer committed twice, ignoring.
wlserver: [types/wlr_compositor.c:771] New wlr_surface 0x5da57181ebe0 (res 0x5da5716aa340)
xwm: got the same buffer committed twice, ignoring.
gamescope: ../gamescope/src/wayland_backend.cpp:688: void gamescope::CWaylandFb::OnCompositorRelease(): Assertion `m_bCompositorAcquired' failed.
fish: Job 1, 'gamescope -w 2560 -h 1440 -W 38…' terminated by signal SIGABRT (Abort)
(EE) failed to write to Xwayland fd: Broken pipe

this is on the latest steam stable
also happens on latest game scope git

inxi -b
System:
  Host: Garuda-Linux Kernel: 6.8.5-1-cachyos arch: x86_64 bits: 64
  Desktop: KDE Plasma v: 6.0.3 Distro: Garuda Linux
Machine:
  Type: Desktop Mobo: ASRock model: X470 Taichi serial: <superuser required>
    UEFI: American Megatrends v: P5.10 date: 10/20/2022
CPU:
  Info: 6-core AMD Ryzen 5 5600X [MT MCP] speed (MHz): avg: 3831
    min/max: 550/4687
Graphics:
  Device-1: AMD Navi 22 [Radeon RX 6700/6700 XT/6750 XT / 6800M/6850M XT]
    driver: amdgpu v: kernel
  Display: wayland server: X.org v: 1.21.1.12 with: Xwayland v: 23.2.6
    compositor: kwin_wayland driver: X: loaded: amdgpu
    unloaded: modesetting,radeon dri: radeonsi gpu: amdgpu resolution:
    1: 2048x864 2: 1396x785 3: 1536x864
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 24.0.4-arch1.2
    renderer: AMD Radeon RX 6700 XT (radeonsi navi22 LLVM 17.0.6 DRM 3.57
    6.8.5-1-cachyos)
Network:
  Device-1: Intel Dual Band Wireless-AC 3168NGW [Stone Peak] driver: iwlwifi
  Device-2: Intel I211 Gigabit Network driver: igb
Drives:
  Local Storage: total: 3.64 TiB used: 4.13 TiB (113.6%)
Info:
  Memory: total: 32 GiB available: 31.26 GiB used: 20.94 GiB (67.0%)
  Processes: 612 Uptime: 11m Shell: fish inxi: 3.3.33
@zany130 zany130 changed the title Games open in an invisible window since 3.14.3 Games open in an invisible window since 3.14.3 when using FSR Apr 11, 2024
@sharkautarch
Copy link

sharkautarch commented Apr 12, 2024

void gamescope::CWaylandFb::OnCompositorRelease(): Assertion `m_bCompositorAcquired' failed.

assertion failure in your output log

@zany130 do you get that assertion failure only when trying to use FSR w/ gamescope?
tho there could be a chance that the assert is only triggered after you manually close the game/gamescope after seeing its window is invisible?
Double check that that assertion fail actually occurs before you close the game/gamescope yourself

@zany130
Copy link
Author

zany130 commented Apr 12, 2024

That happened when I was trying to open the Steam overlay. So I ran the game, heard the game responding to my input, but didn't see the game. Then I tried to open the Steam overlay, and it crashed.

I'll try to see if it still happens without FSR it may be a separate issue

EDIT: nope only happens when using FSR

Updated the OP to clarify I am still running nested under kde

@sharkautarch
Copy link

sharkautarch commented Apr 12, 2024

That happened when I was trying to open the Steam overlay. So I ran the game, heard the game responding to my input, but didn't see the game. Then I tried to open the Steam overlay, and it crashed.

I'll try to see if it still happens without FSR it may be a separate issue

EDIT: nope only happens when using FSR

that assert fail could be a clue then, or it is due to an unrelated bug...
I looked through a bit of the wayland_backend.cpp code, and I have one thought as to the source of at least the assert fail

@Joshua-Ashton m_bCompositorAcquired in wayland_backend.cpp might need to be an atomic, since OnCompositorRelease() is called inside Wayland_Buffer_Release(), which is attached to a wayland event listener thingy ( CWaylandFb::s_BufferListener)
Correct me if it turns out that CWaylandFb::s_BufferListener is always called from the same thread as the ones that OnCompositorRelease() and OnCompositorAcquire() are called on

technically, IncRef() and DecRef() do use atomic inc/dec, and strong atomic ops can sometimes act as barriers around non-atomic ops, but with what I see in OnCompositorRelease() and OnCompositorAcquire(), imo it still wouldn't be safe for m_bCompositorAcquired to be non-atomic
Tho you could probably get away with just using acquire/release atomic ordering for m_bCompositorAcquired

@KyunLFA
Copy link

KyunLFA commented Apr 12, 2024

Hi. I am tripping this assertion and another one upon closing the app gamescope is running. I bisected the offending commits.

The assertion (1) being tripped here started with aec2fd2 . The other one (2) which happens on closing is: src/backend.cpp:60: virtual gamescope::CBaseBackendFb::~CBaseBackendFb(): Assertion '!HasLiveReferences()' failed. . It started from b93b576 . These only happen in nested mode. Couldn't reproduce on embedded mode. The assertions (and crashes) happen very often but sometimes takes a bit to trip.

Backtrace of assertion 1:

#0  0x00007fc1066a053b in pthread_kill () at /usr/lib/libc.so.6
#1  0x00007fc106642048 in raise () at /usr/lib/libc.so.6
#2  0x00007fc106624478 in abort () at /usr/lib/libc.so.6
#3  0x00007fc10662439c in ??? () at /usr/lib/libc.so.6
#4  0x00007fc106637e26 in __assert_fail () at /usr/lib/libc.so.6
#5  0x00005ca687a0ac82 in gamescope::CWaylandFb::OnCompositorRelease (this=0x7fc0c42002c0) at ../src/wayland_backend.cpp:688
#6  0x00005ca687a0ad36 in gamescope::CWaylandFb::Wayland_Buffer_Release (this=0x7fc0c42002c0, pBuffer=0x7fc0c4200240) at ../src/wayland_backend.cpp:702
#7  0x00005ca687a12969 in gamescope::CWaylandFb::$_9::operator()<wl_buffer*> (this=0x7fc0ecfff1a7, pData=0x7fc0c42002c0, args=0x7fc0c4200240)
    at ../src/wayland_backend.cpp:316
#8  0x00005ca687a096fe in gamescope::CWaylandFb::$_9::__invoke<wl_buffer*> (pData=0x7fc0c42002c0, args=0x7fc0c4200240) at ../src/wayland_backend.cpp:316
#9  0x00007fc106d4b2fe in ??? () at /usr/lib/libffi.so.8
#10 0x00007fc106d47264 in ??? () at /usr/lib/libffi.so.8
#11 0x00007fc106d4a74e in ffi_call () at /usr/lib/libffi.so.8
#12 0x00007fc107670620 in ??? () at /usr/lib/libwayland-client.so.0
#13 0x00007fc107670faf in ??? () at /usr/lib/libwayland-client.so.0
#14 0x00007fc1076712bc in wl_display_dispatch_queue_pending () at /usr/lib/libwayland-client.so.0
#15 0x00005ca687a0e897 in gamescope::CWaylandBackend::PollState (this=0x5ca6bf3bd2f0) at ../src/wayland_backend.cpp:1422
#16 0x00005ca68792c49d in steamcompmgr_main (argc=3, argv=0x7ffd6d631958) at ../src/steamcompmgr.cpp:7610
#17 0x00005ca68798ef5f in steamCompMgrThreadRun (argc=3, argv=0x7ffd6d631958) at ../src/main.cpp:933
#18 0x00005ca68798fd3a in std::__invoke_impl<void, void (*)(int, char**), int, char**>
    (__f=@0x5ca6bf5a7ea8: 0x5ca68798ef30 <steamCompMgrThreadRun(int, char**)>, __args=@0x5ca6bf5a7ea0: 3, __args=@0x5ca6bf5a7e98: 0x7ffd6d631958)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/invoke.h:61
#19 0x00005ca68798fca5 in std::__invoke<void (*)(int, char**), int, char**>
    (__fn=@0x5ca6bf5a7ea8: 0x5ca68798ef30 <steamCompMgrThreadRun(int, char**)>, __args=@0x5ca6bf5a7ea0: 3, __args=@0x5ca6bf5a7e98: 0x7ffd6d631958)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/invoke.h:96
#20 0x00005ca68798fc73 in std::thread::_Invoker<std::tuple<void (*)(int, char**), int, char**> >::_M_invoke<0ul, 1ul, 2ul> (this=0x5ca6bf5a7e98)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/std_thread.h:292
#21 0x00005ca68798fc25 in std::thread::_Invoker<std::tuple<void (*)(int, char**), int, char**> >::operator() (this=0x5ca6bf5a7e98)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/std_thread.h:299
#22 0x00005ca68798fa79 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)(int, char**), int, char**> > >::_M_run (this=0x5ca6bf5a7e90)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/std_thread.h:244
#23 0x00007fc106af3843 in std::execute_native_thread_routine (__p=0x5ca6bf5a7e90) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/thread.cc:104
#24 0x00007fc10669e55c in ??? () at /usr/lib/libc.so.6
#25 0x00007fc10672b95c in ??? () at /usr/lib/libc.so.6

Backtrace of assertion 2:

#0  0x00007970ffaa053b in pthread_kill () at /usr/lib/libc.so.6
#1  0x00007970ffa42048 in raise () at /usr/lib/libc.so.6
#2  0x00007970ffa24478 in abort () at /usr/lib/libc.so.6
#3  0x00007970ffa2439c in ??? () at /usr/lib/libc.so.6
#4  0x00007970ffa37e26 in __assert_fail () at /usr/lib/libc.so.6
#5  0x0000637dc149f35d in gamescope::CBaseBackendFb::~CBaseBackendFb (this=0x7970bc2002c0, __in_chrg=<optimized out>) at ../src/backend.cpp:60
#6  0x0000637dc14a2956 in gamescope::CWaylandFb::~CWaylandFb (this=0x7970bc2002c0, __in_chrg=<optimized out>) at ../src/wayland_backend.cpp:672
#7  0x0000637dc14b5807 in std::destroy_at<gamescope::CWaylandFb> (__location=0x7970bc2002c0) at /usr/include/c++/13.2.1/bits/stl_construct.h:88
#8  0x0000637dc14b57ec in std::_Destroy<gamescope::CWaylandFb> (__pointer=0x7970bc2002c0) at /usr/include/c++/13.2.1/bits/stl_construct.h:149
#9  0x0000637dc14b5680 in std::allocator_traits<std::allocator<void> >::destroy<gamescope::CWaylandFb> (__p=0x7970bc2002c0)
    at /usr/include/c++/13.2.1/bits/alloc_traits.h:674
#10 std::_Sp_counted_ptr_inplace<gamescope::CWaylandFb, std::allocator<void>, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x7970bc2002b0)
    at /usr/include/c++/13.2.1/bits/shared_ptr_base.h:613
#11 0x0000637dc13faaf7 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x7970bc2002b0) at /usr/include/c++/13.2.1/bits/shared_ptr_base.h:346
#12 0x0000637dc13ffff3 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x637dec77aac0, __in_chrg=<optimized out>)
    at /usr/include/c++/13.2.1/bits/shared_ptr_base.h:1071
#13 0x0000637dc14ab5b0 in std::__shared_ptr<gamescope::CWaylandFb, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x637dec77aab8, __in_chrg=<optimized out>)
    at /usr/include/c++/13.2.1/bits/shared_ptr_base.h:1524
#14 0x0000637dc14ab5cc in std::shared_ptr<gamescope::CWaylandFb>::~shared_ptr (this=0x637dec77aab8, __in_chrg=<optimized out>)
    at /usr/include/c++/13.2.1/bits/shared_ptr.h:175
#15 0x0000637dc14b53c0 in gamescope::CWaylandBackend::~CWaylandBackend (this=0x637dec77a2f0, __in_chrg=<optimized out>) at ../src/wayland_backend.cpp:446
#16 0x0000637dc14b5478 in gamescope::CWaylandBackend::~CWaylandBackend (this=0x637dec77a2f0, __in_chrg=<optimized out>) at ../src/wayland_backend.cpp:446
#17 0x0000637dc149f259 in gamescope::IBackend::Set (pBackend=0x0) at ../src/backend.cpp:30
#18 0x0000637dc13f14db in steamcompmgr_exit () at ../src/steamcompmgr.cpp:6047
#19 0x0000637dc13f74f0 in steamcompmgr_main (argc=3, argv=0x7fff8a469468) at ../src/steamcompmgr.cpp:7934
#20 0x0000637dc142f272 in steamCompMgrThreadRun (argc=3, argv=0x7fff8a469468) at ../src/main.cpp:933
#21 0x0000637dc142fd09 in std::__invoke_impl<void, void (*)(int, char**), int, char**> (__f=@0x637deca35d28: 0x637dc142f23b <steamCompMgrThreadRun(int, char**)>)
    at /usr/include/c++/13.2.1/bits/invoke.h:61
#22 0x0000637dc142fc4a in std::__invoke<void (*)(int, char**), int, char**> (__fn=@0x637deca35d28: 0x637dc142f23b <steamCompMgrThreadRun(int, char**)>)
    at /usr/include/c++/13.2.1/bits/invoke.h:96
#23 0x0000637dc142fb7d in std::thread::_Invoker<std::tuple<void (*)(int, char**), int, char**> >::_M_invoke<0ul, 1ul, 2ul> (this=0x637deca35d18)
    at /usr/include/c++/13.2.1/bits/std_thread.h:292
#24 0x0000637dc142fb1a in std::thread::_Invoker<std::tuple<void (*)(int, char**), int, char**> >::operator() (this=0x637deca35d18)
    at /usr/include/c++/13.2.1/bits/std_thread.h:299
#25 0x0000637dc142fafe in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)(int, char**), int, char**> > >::_M_run (this=0x637deca35d10)
    at /usr/include/c++/13.2.1/bits/std_thread.h:244
#26 0x00007970ffef3843 in std::execute_native_thread_routine (__p=0x637deca35d10) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/thread.cc:104
#27 0x00007970ffa9e55c in ??? () at /usr/lib/libc.so.6

(tested on master branch with both Clang 18.1.2 and GCC 13.2.1 with either debug on and off, CachyOS Linux)

@sharkautarch
Copy link

sharkautarch commented Apr 12, 2024

@KyunLFA You could try checking for possible data races by building gamescope with thread sanitizer

you'll need to first run this:
sudo sysctl vm.mmap_rnd_bits=28
(this is a workaround for this issue: https://stackoverflow.com/questions/77850769/fatal-threadsanitizer-unexpected-memory-mapping-when-running-on-linux-kernels)
(also you'll probably need to run this before you try building gamescope w/ tsan, since otherwise the build process will fail upon trying to run a test binary built w/ tsan)

Here's the build command(s) I've used for building w/ clang tsan: (clang's sanitizers are a bit more powerful than gcc's)

TSAN_OPTIONS="symbolize=false malloc_context_size=0 detect_leaks=false check_printf=false detect_deadlocks=false intercept_strstr=false intercept_strspn=false intercept_strpbrk=false intercept_memcmp=false history_size=0 report_destroy_locked=0 report_bugs=0 atexit_sleep_ms=0 io_sync=0" UBSAN_OPTIONS=$TSAN_OPTIONS CXX=clang++ CC=clang meson setup --wipe build -Db_lundef=false -Db_lto_mode=thin -Db_sanitize=thread --buildtype=debugoptimized -Dc_args="-shared-libsan -fsanitize-recover=all -fsanitize=undefined -fsanitize=local-bounds -fno-omit-frame-pointer" -Dc_link_args="-fuse-ld=lld -lm /usr/lib/clang/18/lib/linux/libclang_rt.tsan-x86_64.so -lm /usr/lib/clang/18/lib/linux/libclang_rt.ubsan_standalone-x86_64.so -Wl,-rpath,/usr/lib/clang/18/lib/linux/ -shared-libsan -fsanitize-recover=all -fsanitize=undefined  -fsanitize=local-bounds" -Dcpp_args="-shared-libsan -fsanitize-recover=all -fsanitize=undefined -fsanitize=local-bounds -fno-omit-frame-pointer" -Dcpp_link_args="-fuse-ld=lld -shared-libsan -fsanitize-recover=all -fsanitize=undefined -fsanitize=local-bounds  -fno-omit-frame-pointer -lm /usr/lib/clang/18/lib/linux/libclang_rt.tsan-x86_64.so -lm /usr/lib/clang/18/lib/linux/libclang_rt.ubsan_standalone-x86_64.so -Wl,-rpath,/usr/lib/clang/18/lib/linux/"

TSAN_OPTIONS="symbolize=false malloc_context_size=0 detect_leaks=false check_printf=false detect_deadlocks=false intercept_strstr=false intercept_strspn=false intercept_strpbrk=false intercept_memcmp=false history_size=0 report_destroy_locked=0 report_bugs=0 atexit_sleep_ms=0 io_sync=0" UBSAN_OPTIONS=$TSAN_OPTIONS ninja -C build

and then you can run gamescope like so:
TSAN_OPTIONS="atexit_sleep_ms=0 io_sync=0" UBSAN_OPTIONS=$TSAN_OPTIONS gamescope ...

if you get a message complaining about sanitizer library load order, you might need to LD_PRELOAD /usr/lib/clang/18/lib/linux/libclang_rt.tsan-x86_64.so and/or /usr/lib/clang/18/lib/linux/libclang_rt.ubsan_standalone-x86_64.so when running gamescope

@sharkautarch
Copy link

sharkautarch commented Apr 12, 2024

for assertion #1, looking at this line of the backtrace:

#8 0x00005ca687a096fe in gamescope::CWaylandFb::$_9::__invoke<wl_buffer*> (pData=0x7fc0c42002c0, args=0x7fc0c4200240) at ../src/wayland_backend.cpp:316

that corresponds to CWaylandFb::s_BufferListener which I had just been talking about before

so I might have been onto something afterall... though...
maybe the issue isn't simply just that m_bCompositorAcquired isn't atomic, but now that I look at it more, I think there's also another issue with it:

m_bCompositorAcquired is initially set to false
in the CWaylandFb::CWaylandFb() constructor, CWaylandFb::s_BufferListener is set up as an event listener using wl_buffer_add_listener(), but m_bCompositorAcquired should probably be getting set to true within the CWaylandFb::CWaylandFb() constructor, which it currently isn't

So I think there's a race condition that's happening in a short window of time, where if pHostBuffer is released during/after CWaylandFb::CWaylandFb() but before IncRef() is run (IncRef() being called from within OnCompositorAcquire())
then Wayland_Buffer_Release() will be run w/ m_bCompositorAcquired=false

Note that the reason why I mention IncRef() is because it does an atomic increment with the default sequentially consistent memory ordering which will make memory writes before said atomic increment visible to other threads
But note that in this case, if Wayland_Buffer_Release() runs before IncRef(), we still get a race condition
(note: if you are curious about visibility of memory reads, know that on x86_64, memory reads are default visible, but writes are not. tho that is only from the CPU's perspective, not the compiler's)

@sharkautarch
Copy link

@zany130 @KyunLFA
I made a branch wayland_backend_assert1_fix in my fork here: https://github.com/sharkautarch/gamescope/
Let me know whether or not the branch fixes that first assertion failure

@sharkautarch
Copy link

sharkautarch commented Apr 12, 2024

@Joshua-Ashton
This may be unrelated to this issue (not sure), but while running scan-build to check the latest git version of gamescope, I found this warning (tho it could always just be a false-positive idk):

../../../src/backend.cpp:78:14: warning: Use of memory after it is freed [cplusplus.NewDelete]
   78 |         if ( m_pClientBuffer && !uRefCount )

I think that the point where said memory is freed (and then the static analyzer complains about the use-after-free) is when
RcObject::DecRefPrivate() is called from within RcObject::DecRefPrivate
scan-build doesn't give a use-after-free warning if I comment out the DecRefPrivate(); at line 27 in rc.h

At this point, I wonder if it would be simpler to refactor the Rc stuff to just use boost intrusive pointers since I think that does something similar to what the Rc stuff is trying to do... just food for thought
(also see: https://baptiste-wicht.com/posts/2011/11/boost-intrusive_ptr.html
and see example of use in a real project here:
-base class: https://github.com/ceph/ceph/blob/47950f12a30f65c9e4dab3eef9382f77e3b3d82f/src/common/RefCountedObj.h#L81
-implementation: https://github.com/ceph/ceph/blob/main/src/msg/Connection.h#L245)

@KyunLFA
Copy link

KyunLFA commented Apr 12, 2024

@zany130 @KyunLFA I made a branch wayland_backend_assert1_fix in my fork here: https://github.com/sharkautarch/gamescope/ Let me know whether or not the branch fixes that first assertion failure

Did not fix it for me. Now getting gamescope: ../src/wayland_backend.cpp:689: void gamescope::CWaylandFb::OnCompositorRelease(): Assertion 'm_bCompositorAcquired.load(std::memory_order_acquire)' failed..

Backtrace again in case anything changed:

#0  0x0000764e320a053b in pthread_kill () at /usr/lib/libc.so.6
#1  0x0000764e32042048 in raise () at /usr/lib/libc.so.6
#2  0x0000764e32024478 in abort () at /usr/lib/libc.so.6
#3  0x0000764e3202439c in ??? () at /usr/lib/libc.so.6
#4  0x0000764e32037e26 in __assert_fail () at /usr/lib/libc.so.6
#5  0x00005fd4c1ad5fa3 in gamescope::CWaylandFb::OnCompositorRelease (this=0x764df0293a30) at ../src/wayland_backend.cpp:689
#6  0x00005fd4c1ad6076 in gamescope::CWaylandFb::Wayland_Buffer_Release (this=0x764df0293a30, pBuffer=0x764df01fb1a0) at ../src/wayland_backend.cpp:703
#7  0x00005fd4c1add0d9 in gamescope::CWaylandFb::$_9::operator()<wl_buffer*> (this=0x764e0fdff1df, pData=0x764df0293a30, args=0x764df01fb1a0)
    at ../src/wayland_backend.cpp:316
#8  0x00005fd4c1ad5161 in gamescope::CWaylandFb::$_9::__invoke<wl_buffer*> (pData=0x764df0293a30, args=0x764df01fb1a0) at ../src/wayland_backend.cpp:316
#9  0x0000764e327012fe in ??? () at /usr/lib/libffi.so.8
#10 0x0000764e326fd264 in ??? () at /usr/lib/libffi.so.8
#11 0x0000764e3270074e in ffi_call () at /usr/lib/libffi.so.8
#12 0x0000764e3305b620 in ??? () at /usr/lib/libwayland-client.so.0
#13 0x0000764e3305bfaf in ??? () at /usr/lib/libwayland-client.so.0
#14 0x0000764e3305c2bc in wl_display_dispatch_queue_pending () at /usr/lib/libwayland-client.so.0
#15 0x00005fd4c1ad977a in gamescope::CWaylandBackend::PollState (this=0x5fd4e6520160) at ../src/wayland_backend.cpp:1423
#16 0x00005fd4c1a0b362 in steamcompmgr_main (argc=2, argv=0x7ffdc029b608) at ../src/steamcompmgr.cpp:7610
#17 0x00005fd4c1a65f2f in steamCompMgrThreadRun (argc=2, argv=0x7ffdc029b608) at ../src/main.cpp:933
#18 0x00005fd4c1a66a9a in std::__invoke_impl<void, void (*)(int, char**), int, char**>
    (__f=@0x5fd4e67aa7a8: 0x5fd4c1a65f00 <steamCompMgrThreadRun(int, char**)>, __args=@0x5fd4e67aa7a0: 2, __args=@0x5fd4e67aa798: 0x7ffdc029b608)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/invoke.h:61
#19 0x00005fd4c1a66a05 in std::__invoke<void (*)(int, char**), int, char**>
    (__fn=@0x5fd4e67aa7a8: 0x5fd4c1a65f00 <steamCompMgrThreadRun(int, char**)>, __args=@0x5fd4e67aa7a0: 2, __args=@0x5fd4e67aa798: 0x7ffdc029b608)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/invoke.h:96
#20 0x00005fd4c1a669d3 in std::thread::_Invoker<std::tuple<void (*)(int, char**), int, char**> >::_M_invoke<0ul, 1ul, 2ul> (this=0x5fd4e67aa798)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/std_thread.h:292
#21 0x00005fd4c1a66985 in std::thread::_Invoker<std::tuple<void (*)(int, char**), int, char**> >::operator() (this=0x5fd4e67aa798)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/std_thread.h:299
#22 0x00005fd4c1a66809 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)(int, char**), int, char**> > >::_M_run (this=0x5fd4e67aa790)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/std_thread.h:244
#23 0x0000764e324f3843 in std::execute_native_thread_routine (__p=0x5fd4e67aa790) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/thread.cc:104
#24 0x0000764e3209e55c in ??? () at /usr/lib/libc.so.6
#25 0x0000764e3212b95c in ??? () at /usr/lib/libc.so.6

@Joshua-Ashton
Copy link
Collaborator

@sharkautarch Definitely opposed to any boost crap, we can just store m_pClientBuffer in DecRef before the base class call.

@Joshua-Ashton
Copy link
Collaborator

The assertion is because of how composition output buffers are handled fundamentally not working with how Wayland buffer release works. I need to rewrite that code to be smarter and pick images based on which are free.

@sharkautarch
Copy link

Definitely opposed to any boost crap

good to know

The assertion is because of how composition output buffers are handled fundamentally not working with how Wayland buffer release works.

Ah I see

I need to rewrite that code to be smarter and pick images based on which are free.

Well good luck, that sounds like a bit of a pain...

@DJXJD
Copy link

DJXJD commented Apr 13, 2024

I'm experiencing something similar on my end. As of 3.14.3 (downgrading to 3.14.2 fixes the issue), launching with FSR causes the window to show up not quite invisible, but extremely transparent and over-saturated. Toggling off FSR with super + u brings things back to normal, but then toggling on any other form of up-scaling via keyboard shortcut makes the window appear to be frozen. Toggling off that up-scaling again brings things back to normal, but also shows that the window was still interact-able while appearing frozen.

For reference, I'm on arch, with hyprland 0.38.1-1

@sharkautarch
Copy link

Ah, it looks like Joshua Ashton has fixed the use-after-free bug that I had found w/ scan-build.
Though unfortunately it’ll still take him some time to fix the assert issue
I’m sure he’ll figure it out, he’s a good dev :)

@Cryolitia
Copy link

I'm trying to start waydroid in gamescope, and meet the same fault.

gamescope: ../src/wayland_backend.cpp:688: void gamescope::CWaylandFb::OnCompositorRelease(): Assertion `m_bCompositorAcquired' failed.
2024-04-22.13-31-56.webm

@Joshua-Ashton
Copy link
Collaborator

You can comment out that assertion for now, but you might get visual glitching

@zany130
Copy link
Author

zany130 commented May 6, 2024

So, update on this issue. I tried the latest commit and FSR still shows a blank image. I'm guessing that just needs to be fixed but the really interesting thing is that it sorta works with nis... except an old copy of the screen is overlayed on top...

trying to see how I can upload a screen shot here it comes out to big for github (prob because its 4k)

EDIT:Screenshot_%T_%d

So the "bottom" image is correct and responds to input while the top "overlayed image is static

@exalented
Copy link

Something I've noticed is that this seems to be happening with the Nvidia generations Pascal and older. I have a 1080. This only happens when not full-screen otherwise it's black. gamescope 3.14.3-1
nis has never worked for me. I see effectively the same results as fsr in this issue.

System:
  Host: ArchTower Kernel: 6.8.9-arch1-1 arch: x86_64 bits: 64
  Desktop: Sway v: 1.9 Distro: Arch Linux
Graphics:
  Device-1: NVIDIA GP104 [GeForce GTX 1080] driver: nvidia v: 550.78
  Display: wayland server: X.org v: 1.21.1.13 with: Xwayland v: 21.1.99
    compositor: Sway v: 1.9 driver: X: loaded: modesetting,nvidia
    gpu: nvidia,nvidia-nvswitch resolution: 1: 1920x1080~60Hz
  API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 550.78
    renderer: NVIDIA GeForce GTX 1080/PCIe/SSE2

@llyyr
Copy link

llyyr commented Jun 9, 2024

@Joshua-Ashton I was able to bisect this to 92f28b0

Although my issue might be unrelated, because gamescope never launches in nested mode no matter what (unrelated to using FSR)

edit: fixed by this diff

diff --git a/src/steamcompmgr.cpp b/src/steamcompmgr.cpp
index 0edc4bbe036e..210150ddb73b 100644
--- a/src/steamcompmgr.cpp
+++ b/src/steamcompmgr.cpp
@@ -6997,7 +6997,7 @@ void init_xwayland_ctx(uint32_t serverId, gamescope_xwayland_server_t *xwayland_
 		else
 		{
 			xwm_log.infof( "Embedded, no cursor set. Using left_ptr by default." );
-			if ( !ctx->cursor->setCursorImageByName( "left_ptr" ) )
+			if ( !ctx->cursor->setCursorImageByName( "default" ) )
 				xwm_log.errorf( "Failed to load mouse cursor: left_ptr" );
 		}
 	}

@Joshua-Ashton
Copy link
Collaborator

Does your cursor theme not have left_ptr? That should not be fatal anyway.

@llyyr
Copy link

llyyr commented Jun 9, 2024

Does your cursor theme not have left_ptr? That should not be fatal anyway.

It does not, duplicating the "default" cursor as "left_ptr" fixes it as well. My cursor does not have any of the fallback names listed here https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/xcursor/wlr_xcursor.c?ref_type=heads#L262-292 but it does have the names wlroots tries for first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants