Gamescope process hangs when all applications die

[MCPO-Spartan-117]

Is there an existing issue for this?

• I have searched the existing issues

Are you using any gamescope patches or a forked version of gamescope?

• The issue occurs on upstream gamescope without any modifications

Current Behavior

Started from commit: a493c58
Gamescope hangs when all applications die, killing the only application results in gamescope's window dying but the process is still going, in embedded the display doesn't come back until killing gamescope.
Couldn't test SDL at all in Wayland for some reason.

Steps To Reproduce

1. Start gamescope with application
2. Kill application
3. Gamescope hangs

Hardware information

- Distro: `Artix`
- CPU: `i7-7700K`
- GPU: `RX 6700XT`
- Driver Version: `Mesa 24.2.3 (git-ebd2c2e668) (LLVM 18.1.8)`

Software information

- Desktop environment: `Hyprland`, `TTY`
- Session type: `wayland`, `embedded`
- Gamescope version: `gamescope version 3.15.9-21-g7dd1bcd9 (gcc 14.2.1)`
- Gamescope launch command(s): `gamescope -- urxvt -bg black -fg blue +sb`, `gamescope -- vkcube`

Which gamescope backends have the issue you are reporting?

• Wayland (default for nested gamescope)
• DRM (default for embedded gamescope, i.e. gamescope-session)
• SDL
• OpenVR

Logging, screenshots, or anything else

temp.log

[matte-schwartz]

I'm not quite sure why, but attempting to attach gamescopestream seems to cause gamescope to shut down without sending a terminate signal when it's in this state. I tried re-building gamescope without pipewire enabled to see if maybe that would change the hang, but it had no effect.

[sharkautarch]

@MCPO-Spartan-117 for debugging, try running this command:
ltrace -C -x 'lua*' -x '*libc*' -x 'CScript*' -x '*mutex*' -x '*CWayland*' -x 'sol::*' -x 'static_initialization*' -f -- gamescope <params...> |& tee gamescope_ltrace.out

[the-burrito-triangle]

This also happens for me on Fedora 40 and 41. Works fine on Fedora 39 though (with gamescope 3.13.19).

I guess new versions of Gamescope don't play well with upstream Wine?

[matte-schwartz]

This also happens for me on Fedora 40 and 41. Works fine on Fedora 39 though (with gamescope 3.13.19).

I guess new versions of Gamescope don't play well with upstream Wine?

The regressing commit for this issue has not made it into Fedora 40 or Fedora 41, as it is not in a tagged Gamescope release yet. Maybe you are thinking of #1482?

[the-burrito-triangle]

You're right #1482 matches what I've encountered on Fedora. Sorry for the noise!

[MCPO-Spartan-117]

@sharkautarch Without *libc* and *mutex* gamescope works like expected, with it outputs a lot then stops processing, gamescope never showing up.

[sharkautarch]

@MCPO-Spartan-117
Yeah, sorry for not updating, but Matt & I experimented more with ways of tracing gamescope hanging at exit on the Linux game dev discord. Saw that that cmd was problematic, sorry for not updating on that in this issue

Also noticed a further problem from Matt’s traces, where it seemed like the output was missing a lot of info compared to the traces I did on my own gamescope binary
Which I believe is due to Matt’s binary having been compiled with -fomit-frame-pointer
Where some distros use that parameter by default & also gcc might also use -fomit-frame-pointer by default when optimizations are on
Also I’ve realized that ltrace might not be designed for tracing a static executable’s functions (it’s only documented as being used to trace shared library functions), so I’m now working on helping Matt use perf dynamic user function tracing, but again it seems like there’s the same issue w/ -fomit-frame-pointer