Some X11 applications(?) (e.g.VSCode/Codium) freeze the whole system (does recover) with KDE Host

[KirmesBude]

Describe the bug When using VSCode/Codium inside the toolbox, the whole system regularly freezes for >=1 second. Especially easily reproducible if hovering over any of the menus. The VSCode/Codium themeing also does not look themed correct, so maybe this is part of the problem. I do not face this problem with my laptop running silverblue 35.

Steps how to reproduce the behaviour

1. Create and enter a toolbox
2. install vscode/codium
3. run vscode/codium

Expected behaviour I can use vscode/codium from within the toolbox no problem.

Actual behaviour The whole system freezes. Sometimes for multiple seconds.

Screenshots https://youtu.be/byqXiMcQ-bs

Output of toolbox --version (v0.0.90+) toolbox version 0.0.99.3

Toolbox package info (rpm -q toolbox) toolbox-0.0.99.3-2.fc35.x86_64

Output of podman version

Version:      3.4.7
API Version:  3.4.7
Go Version:   go1.16.15
Built:        Thu Apr 21 15:14:26 2022
OS/Arch:      linux/amd64

Podman package info (rpm -q podman) podman-3.4.7-1.fc35.x86_64

Info about your OS Kinoite 35

Additional context Host Flatpacked codium works normally. I am not sure if this is the right place to put this bug report. Seems to be Kinoite specific. I would be interested in any tips on how to proceed with troubleshooting.

[HarryMichal]

Hi @KirmesBude! This sounds like a tricky bug.

I do not face this problem with my laptop running silverblue 35.

Is that on the same machine? As far as I know the only difference between Silverblue and Kinoite should be the desktop environment.

Host Flatpacked codium works normally.

This probably tells us it's not because of the graphics stack? And it's Flatpak :wink:

Could you also try to run VSCode from an RPM, please?

I am not sure if this is the right place to put this bug report.

One could go through Kinoite's bug tracker but myself am not actually sure where that is.

I would be interested in any tips on how to proceed with troubleshooting.

I would suggest you watch the journal (journalctl) and run VSCode with debug logging enabled.

[KirmesBude]

I do not face this problem with my laptop running silverblue 35.

Is that on the same machine? As far as I know the only difference between Silverblue and Kinoite should be the desktop environment.

It is not. There are two different machines, my desktop with Kinoite and my laptop with Silverblue. Desktop uses an AMD Processor and dGPU. Laptop uses an Intel Processor with iGPU.

Host Flatpacked codium works normally.

This probably tells us it's not because of the graphics stack? And it's Flatpak wink

Could you also try to run VSCode from an RPM, please?

Good point. I just layered the codium rpm ontop and I am unable to reproduce the problem there. The theming is also correct there - no white top bar.

I am not sure if this is the right place to put this bug report.

One could go through Kinoite's bug tracker but myself am not actually sure where that is.

I think I found it. Will see if I am able to open up an issue there as well.

I would be interested in any tips on how to proceed with troubleshooting.

I would suggest you watch the journal (journalctl) and run VSCode with debug logging enabled.

https://gist.github.com/KirmesBude/65f60cba40109694650c91c7b9a46cd6

I already did that, but I was not able to find anything interesting. Sometimes "kwin_core: XCB error: 3 (BadWindow), sequence: 2615, resource id: 16777254, major code: 129 (SHAPE), minor code: 6 (Input)" corresponds to the freeze, but no always.

[HarryMichal]

It is not. There are two different machines, my desktop with Kinoite and my laptop with Silverblue. Desktop uses an AMD Processor and dGPU. Laptop uses an Intel Processor with iGPU.

Hmm... would be nice to compare the outcome on Silverblue on the same machine. If you're willing, could you rebase your system running Kinoite on Silverblue?

The theming is also correct there - no white top bar.

The white top bar is expected because the dark Adwaita theme is not installed by default in Fedora images. We could probably do that? But that is a different topic.

https://gist.github.com/KirmesBude/65f60cba40109694650c91c7b9a46cd6

Might be worth trying to install mesa drivers in the container to see if that changes anything. I think the relevant packages are mesa-dri-drivers and mesa-vulkan-drivers.

[KirmesBude]

Hmm... would be nice to compare the outcome on Silverblue on the same machine. If you're willing, could you rebase your system running Kinoite on Silverblue?

I will try this tomorrow.

The white top bar is expected because the dark Adwaita theme is not installed by default in Fedora images. We could probably do that? But that is a different topic.

Yeah, I figured. Just wanted to mention it.

Might be worth trying to install mesa drivers in the container to see if that changes anything. I think the relevant packages are mesa-dri-drivers and mesa-vulkan-drivers.

My container already has those installed. I checked with a newly created container just to make sure the inverse is not the case, but I face the same issue there.

Thanks for the timely replies btw. Really appreciated :)

[ashquarky]

I've got this issue too! I initially blamed on an Ubuntu container I was using but it seems Fedora containers have the issue. (Other discussion in https://github.com/containers/toolbox/pull/483#issuecomment-1132778147)

I've been able to reproduce this with VSCodium and qhexedit in a fedora container, as well as mgba and various ROS qt apps in an ubuntu container. All of these apps used X11 (as evidenced by their blurry appearance on my HiDPI display) rather than Wayland protocols, and I'm running Wayland on KDE on the host. Fedora KDE 35, not Kionite.

I think it's a DNS issue, since adding toolbox to the host's /etc/hosts file seems to fix it. (This file also seems to be forwarded into the container though, so who knows.)

hosts and nsswitch, both identical in toolbox and host:

127.0.0.1   toolbox localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         toolbox localhost localhost.localdomain localhost6 localhost6.localdomain6

hosts:      files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

My suspicion is that kwin is trying to resolve the name "toolbox". Is it expected for <@toolbox> to be appended to the window titles, and could that be related?

[KirmesBude]

That does appear to fix it :D How did you even come up with that.

[ashquarky]

I remembered reading something about it while trying to get an ubuntu container working, people were talking about it fixing long delays in sudo.. the actual solution turned out to be an nsswitch tweak but hopefully this info can at least get the more knowledgeable people on the right track? It's also a pretty good workaround for the rest of us :sweat_smile:

[jnohlgard]

1215 fixes the random freezes in IntelliJ and other IDEs on my machine. Host system: Fedora Kinoite 37, Plasma Wayland session.

[leonewton253]

I've got this issue too! I initially blamed on an Ubuntu container I was using but it seems Fedora containers have the issue. (Other discussion in #483 (comment))

I've been able to reproduce this with VSCodium and qhexedit in a fedora container, as well as mgba and various ROS qt apps in an ubuntu container. All of these apps used X11 (as evidenced by their blurry appearance on my HiDPI display) rather than Wayland protocols, and I'm running Wayland on KDE on the host. Fedora KDE 35, not Kionite.

I think it's a DNS issue, since adding toolbox to the host's /etc/hosts file seems to fix it. (This file also seems to be forwarded into the container though, so who knows.)

hosts and nsswitch, both identical in toolbox and host:

127.0.0.1   toolbox localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         toolbox localhost localhost.localdomain localhost6 localhost6.localdomain6

hosts:      files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

My suspicion is that kwin is trying to resolve the name "toolbox". Is it expected for <@toolbox> to be appended to the window titles, and could that be related?

This should be default in Kinoite and Silverblue. Fixed my issues with several GUI apps.

[r2com]

I've got this issue too! I initially blamed on an Ubuntu container I was using but it seems Fedora containers have the issue. (Other discussion in #483 (comment))

I've been able to reproduce this with VSCodium and qhexedit in a fedora container, as well as mgba and various ROS qt apps in an ubuntu container. All of these apps used X11 (as evidenced by their blurry appearance on my HiDPI display) rather than Wayland protocols, and I'm running Wayland on KDE on the host. Fedora KDE 35, not Kionite.

I think it's a DNS issue, since adding toolbox to the host's /etc/hosts file seems to fix it. (This file also seems to be forwarded into the container though, so who knows.)

hosts and nsswitch, both identical in toolbox and host:

127.0.0.1   toolbox localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         toolbox localhost localhost.localdomain localhost6 localhost6.localdomain6

hosts:      files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

My suspicion is that kwin is trying to resolve the name "toolbox". Is it expected for <@toolbox> to be appended to the window titles, and could that be related?

damnit you are a life saver!!!! I had same issues when trying to run jetBrains Toolbox (not to be confused with toolbox) from inside my newly created toolbox.

I would have freezing every 6-7 seconds for 1-2 seconds, editing /etc/hosts fixed it!

additionally, for those who plan to run same tool, this also needs to be installed to run jetbrains toolbox: sudo dnf install libsecret fuse fuse3 fuse-libs libadwaita