Flatpak version crash on X11

[madscientist16]

Describe the bug
A while after starting the app it just crashes

To Reproduce
Steps to reproduce the behavior:

1. Start ProtonUp-Qt
2. App closes itself after a while

Expected behavior
ProtonUp-Qt to stay open

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• Platform: Laptop
• System: Arch Linux with Plasma 5.27.8 on X11
• Version: ProtonUp-Qt 2.8.2
• How did you install ProtonUp-Qt?: Flatpak

Additional context Works on wayland.

Terminal output

ProtonUp-Qt 2.8.2 by DavidoTek. Build Info: DavidoTek Flathub build.
Python 3.10.13 (main, Nov 10 2011, 15:00:00) [GCC 12.2.0], PySide 6.5.2
Platform: KDE Flatpak runtime 6.5 Linux-6.5.7-zen1-1-zen-x86_64-with-glibc2.35
Qt: Session management error: Could not open network socket
QGuiApplication::setDesktopFileName: the specified desktop file name ends with .desktop. For compatibility reasons, the .desktop suffix will be removed. Please specify a desktop file name without .desktop suffix
Loading locale en / en_US
Loaded ctmod GE-Proton
Loaded ctmod Wine-GE
Loaded ctmod Boxtron
Loaded ctmod D8VK (nightly)
Loaded ctmod Kron4ek Wine-Builds Vanilla
Loaded ctmod Lutris-Wine
Loaded ctmod Luxtorpeda
Loaded ctmod NorthStar Proton (TitanFall 2)
Loaded ctmod Proton Tkg
Loaded ctmod Proton Tkg (Wine Master)
Loaded ctmod Roberta
Loaded ctmod Steam-Play-None
Loaded ctmod SteamTinkerLaunch
Loaded ctmod SteamTinkerLaunch-git
Loaded ctmod vkd3d-lutris
Loaded ctmod vkd3d-proton
Loaded ctmod Wine Tkg (Valve Wine)
Loaded ctmod Wine Tkg (Vanilla Wine)
Loaded ctmod DXVK
Loaded ctmod DXVK Async
Loaded ctmod DXVK (nightly)
qt.pysideplugin: Environment variable PYSIDE_DESIGNER_PLUGINS is not set, bailing out.
qt.pysideplugin: No instance of QPyDesignerCustomWidgetCollection was found.
Gamepad error: No gamepad found.

[sonic2kk]

It closes itself after a while? As in, it doesn't close itself immediately?

Is the terminal output you provided from when a crash occurs? If not, could you open ProtonUp-Qt from terminal and wait until a crash occurs, then copy and paste in the terminal output from directl after the crash?

If you did already do that, then I'm not immediately seeing anything that would point to why the crash occurs. These two lines are suspicious but should not cause a crash afaik:

Qt: Session management error: Could not open network socket
QGuiApplication::setDesktopFileName: the specified desktop file name ends with .desktop. For compatibility reasons, the .desktop suffix will be removed. Please specify a desktop file name without .desktop suffix

The .desktop issue is already fixed on main, but the network socket warning does sound strange.

---

I wonder if this is a regression with something outside of ProtonUp-Qt? Such as a Flatpak runtime. I will try test on my Steam Deck later, as that's the only Plasma X11 device I have.

Out of interest, does this happen with the AppImage?

[madscientist16]

It doesn't close immediately and that is the output after the crash. AppImage version works fine.

[sonic2kk]

Sounds like it's some Flatpak runtime issue then, if the AppImage works fine. Couldn't find anything from a very cursory search, and it doesn't look like there's a KDE Flatpak runtime update available (though it was hard to find much concrete info, further confirmation would be appreciated).

The ProtonUp-Qt Flatpak repository is over at flathub/net.davidotek.pupgui2, though I don't see anything immediately from the Flatpak packaging that would suggest a crash.

If you use a tool like Flatseal and use/confirm the following settings, does the situation improve?

• Enable Wayland Socket
• Disable X11 Socket
• Enable Fallback X11 socket

KDE also provies a way to modify this in the system settings, though it's under "Advanced Permissions" and the UI for it is a lot less friendly imo.

It shouldn't change much, but I know this is becoming more of the default, so perhaps for Flatpak there are some behaviour differences between using these options, and runtimes expect whatever behaviour is given by fallback-x11. I doubt it honestly though, but was just wondering.

---

@DavidoTek Do you know how likely this is to be an upstream issue with some Flatpak runtimes, i.e. has something like this happened before? :slightly_smiling_face:

[madscientist16]

Changing sockets didn't make a difference.

[DavidoTek]

Thanks for already looking into the issue

Qt: Session management error: Could not open network socket Enable Fallback X11 socket

I think that issue could be anything related to network sockets. It possible that it is caused by the X11/Wayland connection and related to https://github.com/DavidoTek/ProtonUp-Qt/issues/284 as sonic2kk mentioned. When searching that issue on the internet, there are several unrelated threads (some issue with VLC which is also based on Qt and some Intel software that crashes when running a VNC) that talk about clearing some sort of cache and unsetting the environmental variable SESSION_MANAGER (run unset SESSION_MANAGER) though I think that should happen when rebooting your computer ("Have you tried turning it off and on again?" :smile:).

Do you know how likely this is to be an upstream issue with some Flatpak runtimes, i.e. has something like this happened before? 🙂

I can't remember anything like it off the top of my head...

[madscientist16]

I did try rebooting and it still crashes

[DavidoTek]

Can you try running ProtonUp-Qt with Qt plugin debugging enabled:

QT_DEBUG_PLUGINS=1 flatpak run net.davidotek.pupgui2

I did try rebooting and it still crashes

I have no clue whether the issue is actually related to the SESSION_MANAGER, but could you also try running unset SESSION_MANAGER and then run ProtonUp-Qt using the above command in the same Terminal window and see if it still crashes?

---

The output of the commands with debugging enabled can be quite long. Can you maybe post them using https://gist.github.com/ or pastebin?

[madscientist16]

https://pastebin.com/ewKATNZk still crashes after running unset SESSION_MANAGER

[sonic2kk]

Possibly related, Prism Launcher Flatpak (another Qt application, though Qt5 afaik which seems to be using Qt 6.5!) seems to have recently had this issue with KDE X11 (https://github.com/PrismLauncher/PrismLauncher/issues/1674), though on Fedora and not Arch. It was also reported on that issue that the AppImage version works, but not the Flatpak. Very strikingly similar details.

It's possible that this could be an upstream Qt problem when running an X11 session, though I wonder if it's just limited to KDE... all my machines except my Steam Deck run the latest KDE Plasma Wayland, and I think the Steam Deck is behind a bit with the Plasma version, so if the Steam Deck doesn't have this problem I suspect it could be an issue specific to Qt Flatpak applications with newer Plasma versions on an X11 session.

EDIT: It seems according to that Prism issue, it's also Qt6.5, so this could be a Qt problem.

[DavidoTek]

EDIT: It seems according to that Prism issue, it's also Qt6.5, so this could be a Qt problem.

PySide 6.6.0 is available since yesterday. KDE Runtime 6.6 doesn't seem to be available on Flatpak yet. When it is, we can upgrade. (6.6 is not an LTS release, but I read today that all future updates to 6.5 LTS are commercial only, so we may upgrade).

[sonic2kk]

Sorry if this is a silly question but for my own understanding, is it the KDE Runtime that provides PySide6 for Flatpak, or what's the dependency here? Maybe the Qt libraries that PySide depends on are provided by the KDE Runtime (since KDE is built with Qt)?

Not trying to contest upgrading by any means, I'm just wondering :-)

Currently there is a Qt6.6 branch for the KDE Runtime, so it should hopefully be out in the near future. They seem to be on top of it 😄

[DavidoTek]

Sorry if this is a silly question but for my own understanding, is it the KDE Runtime that provides PySide6 for Flatpak, or what's the dependency here?

There are no silly questions ;)

We are depending on the Qt libs provided by the KDE Runtime.

Before commit https://github.com/flathub/net.davidotek.pupgui2/commit/6741fe52a49b1c651f7b9e35e6f97a8d69389122, we used to build PySide6 from source and directly depend on the libraries. The current method is a bit hacky: PySide6 is downloaded normally from PyPi which also includes the Qt libraries in addition to the Python bindings. What the script does is to just delete the duplicate libraries. That should work fine as long as the minor version of Qt matches (as in 6.3.0/6.3.1/6.3.2 work with 6.3).

https://github.com/flathub/net.davidotek.pupgui2/blob/6daba87bb09fb112e4cd84dbbe879d32b7f8f2e1/net.davidotek.pupgui2.json#L56

Currently there is a Qt6.6 branch

I saw that too, but flatpak install org.kde.Platform//6.6 isn't available yet.

---

I'm not 100% sure if this issue here actually is caused by Qt directly as I would consider it to be a rather professional software, so it could also be something else related to the window manager or some combination which only happens in some edge cases. Nevertheless, keeping it somewhat up to date seems like a good idea (and ideally reduces the number of Flatpak runtimes you need have installed)

PR when it becomes available. We may even need to update that as some patches to PySide 6.6 might be out until then. https://github.com/flathub/net.davidotek.pupgui2/pull/25

[madscientist16]

I have something to add to this. After a reboot running protonup doesn't show any terminal output and crashes without the GUI appearing. Running protonup again shows the GUI for a while and crashes as described in this issue.

[DavidoTek]

After a reboot running protonup doesn't show any terminal output and crashes without the GUI appearing

So the output looks kinda like the this?

[user@system ~]$ flatpak run net.davidotek.pupgui2
[user@system ~]$

That sounds more like a problem with Flatpak/some other part of your installation and unrelated to ProtonUp-Qt. It is possible that there is a buggy version of something in the Arch repos.

[madscientist16]

Yes the output looks like that.

[DavidoTek]

Okay, it's probably not related to ProtonUp-Qt then but rather some problem with the os. I will close this issue.

If you should have any more insights later that might be relevant (maybe if it is caused by some buggy Qt version), feel free to leave them here.