foot window freezes until keybinding is pressed

NikitaIvanovV commented 1 year ago

Info

dwl version: dwl v0.4-16-g797e0c7 wlroots version: 0.16.2

Description

Sometimes when I use foot and press any key, the window "freezes" and does not update. Once I press some dwl keybinding (e.g. switch to another workspace or change focus), the window gets refreshed. I'm not sure if only foot gets frozen when it happens, I presume the entire screen is affected.

When it happens I get this line in stderr:

[2023-05-23 23:27:45] 00:29:06.149 [ERROR] [backend/drm/atomic.c:72] connector eDP-1: Atomic commit failed: Device or resource busy

This might by unrelated, but in case it is, I have a similar issue that does not happen as often, although it is more severe. Sometimes the screen gets frozen when using any program (not just foot) but it's impossible to fix with a keybinding. The only thing I can do is quit() dwl. However, sometimes even that function does not work and I have to forcefully power off my machine. I noticed that it happens after I relaod my config by exiting dwl and going back. I run exec dwl -s dwlb in ~/.bash_profile.

NikitaIvanovV commented 1 year ago

Most of the time it happens when I work in nvim or when I exit nvim or less (I think at that point foot switches from displaying alternative screen to the main one, although I do not see how it would affect dwl).

NikitaIvanovV commented 1 year ago

I tested with Alacritty and the error does not happen there.

Also, I firgured out that the error occures after this line when the function returns 0:

https://github.com/djpohly/dwl/blob/797e0c74b2cbf4a49f83c9269abec06f3293d00c/dwl.c#L1890

yveszoundi commented 1 year ago

I don't know if it's the same underlying issue, but I have also observed occasional "full system freeze" issues, with no recovery possible or known workaround.

This happens when using Firefox or some of its variants such as LibreWolf in Wayland mode, with sites that periodically update parts of the page for notifications (LinkedIn, GitHub, ProtonMail, etc.).
Keys processing seems to be also be impacted and stops working (switching to tty or whatever)

Whenever that happens, I forcibly power-off the machine. Because I'm mostly using emacs, foot and firefox, I'm led to believe that it could be a pure Firefox problem.

I've seen this happen with Arch Linux and Slackware so far.
The issue only manifests itself randomly when I have a browser such as Firefox open, as far as I know

NikitaIvanovV commented 1 year ago

Found these issues:

https://github.com/swaywm/sway/issues/7519 https://github.com/swaywm/wlroots/issues/2087 https://codeberg.org/dnkl/foot/issues/350 https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3507

I tried adding export WLR_DRM_NO_ATOMIC=1 and apparently it fixes the freeze issues. Instead I started getting some rendering artifacts but it's tolerable.

I tend to think it's a dwl issue because I used river before, which is based on wlroots as well, and it had no issues.

sevz17 commented 1 year ago

I don't know if it's the same underlying issue, but I have also observed occasional "full system freeze" issues, with no recovery possible or known workaround.

This is a different issue, see https://github.com/djpohly/dwl#status-information

sevz17 commented 1 year ago

@NikitaIvanovV can you check #423?

NikitaIvanovV commented 1 year ago

I started getting artifacts similar to those when I set WLR_DRM_NO_ATOMIC=1, however, sometimes (less often than before) window freezes but it only requires one random key press to unfreeze it. Freezes that affect entire dwl still persist when I start/kill dwl a bunch of times.

To clarify, foot freezes happen on my laptop with scale set to 2, on my monitor it does not happen. Freezes that affect entire dwl happen on both outputs.

Btw, to kill dwl I usually do loginctl kill-session ''. Could it be a reason why I get a freeze after several times of doing it because systemd didn't allow dwl to free some resources?

NikitaIvanovV commented 1 year ago

Looks like they fixed it in river by implementing damage tracking: https://github.com/riverwm/river/pull/296/files

sevz17 commented 1 year ago

Freezes that affect entire dwl still persist when I start/kill dwl a bunch of times.

Can you SSH in and run this command gdb --pid=$(pidof dwl) --ex 'set logging enabled on' --ex 'bt full' --ex 'exit' and send me gdb.txt?

Btw, to kill dwl I usually do loginctl kill-session ''. Could it be a reason why I get a freeze after several times of doing it because systemd didn't allow dwl to free some resources?

I don't think so, when a program is terminated the kernel does free all the resources associated.

sevz17 commented 1 year ago

Looks like they fixed it in river by implementing damage tracking: https://github.com/riverwm/river/pull/296/files

We use scene API, which implements damage tracking for us.

NikitaIvanovV commented 1 year ago

To some reason freezing after restarting dwl multiple times stopped happenning. Maybe it was got fixed in wlroots?

As for freezing in foot, it's still happenning. And I've noticed that it happens way less with alpha setting set to 1.0.

fbushstone commented 11 months ago

I don't know if it's the same underlying issue, but I have also observed occasional "full system freeze" issues, with no recovery possible or known workaround.

This happens when using Firefox or some of its variants such as LibreWolf in Wayland mode, with sites that periodically update parts of the page for notifications (LinkedIn, GitHub, ProtonMail, etc.).

Keys processing seems to be also be impacted and stops working (switching to tty or whatever)

Whenever that happens, I forcibly power-off the machine. Because I'm mostly using emacs, foot and firefox, I'm led to believe that it could be a pure Firefox problem.

I've seen this happen with Arch Linux and Slackware so far.

The issue only manifests itself randomly when I have a browser such as Firefox open, as far as I know

You can also reproduce it by opening st in one tag, chromium in another, and quickly switching between tags until the system freezes.

yveszoundi commented 11 months ago

Glad to known that at least it's easily reproducible @fbushstone

I was still experiencing a full system freeze (the dwl virtual machine) multiple times per day and it became too frustrating.

Open only 2 applications such as a browser (firefox) and a terminal (foot with GNU screen and GNU emacs running)
In the browser, signin in Protonmail and GitHub, and do nothing
In another virtual machine, do some work for 1 hr or more
Go back to the dwl virtual machine and then notice that it's completely frozen (similar to those old X locked up bugs)

For now, I've moved all my browsing activities to a dedicated virtual machine with my old dwm setup.

I still run dwl in some virtual machines, but with very dedicated purposes ("password-manager-vm", "program-and-do-it-all-in-emacs-vm", etc.).

sevz17 commented 11 months ago

@fbushstone, @yveszoundi, can you SSH in and run this command gdb --pid=$(pidof dwl) --ex 'set logging enabled on' --ex 'bt full' --ex 'exit' and send me gdb.txt?

PalanixYT commented 11 months ago

You can also reproduce it by opening st in one tag, chromium in another, and quickly switching between tags until the system freezes.

This sounds like stdout is getting filled up. Have you tried closing it properly? You can use <&-

yveszoundi commented 11 months ago

Maybe @PalanixYT wild guesses are correct (printstatus function??), I can't really tell.

@sevz17 , I forgot that I'm running dwl-guile on my machines nowadays, so I'll try providing a gdb output for dwl master later. Meanwhile, maybe what I've collected could give few hints.

My environment

OS: Slackware 15 (Linux guest from Mac OS host)
Virtualization software: QEMU (installed via pkgin)
Memory allocated to the VM: 5 GB of ram
Applications running: dwl, Quassel (no pesonal activity), Firefox (no xwayland here), GNU screen terminal with just a ksh prompt (no pesonal activity)
Dwl: Latest dwl-guile
Dwl status bar: Latest dtao-guile

What was going on prior the freeze in Firefox

I had Firefox open with 3 tabs: GitHub, Protonmail and LinkedIn
After 2 days and very basic clicks between tabs, nothing was happening
I tried uploading few release artifacts for one of my GitHub projects (3 files of ~36 MB) and then dwl froze
- In the past I typically uploaded more files of the same size at once, without issues
- I've also noticed a while back dwl freezing after (few days of zero activity) on the Linkedin tab (maybe due to firefox and UI notifications??)

Gdb command via ssh

gdb --pid=REPLACE_ME --ex 'set logging on' --ex 'bt full' --ex 'quit'

Gdb output

gdb.txt output

``` #0 0x00007f0bf3bc54df in write () at /lib64/libc.so.6 #1 0x00007f0bf3b4b9d5 in _IO_file_write@@GLIBC_2.2.5 () at /lib64/libc.so.6 #2 0x00007f0bf3b4d381 in __GI__IO_do_write () at /lib64/libc.so.6 #3 0x00007f0bf3b4c185 in __GI__IO_file_xsputn () at /lib64/libc.so.6 #4 0x00007f0bf3b36b2d in __vfprintf_internal () at /lib64/libc.so.6 #5 0x00007f0bf3b21e1e in printf () at /lib64/libc.so.6 #6 0x0000000000416f95 in printstatus () at dwl.c:2012 m = 0x9cde90 c = 0xa12630 occ = 7 urg = 0 sel = 2 #7 0x0000000000415514 in focusclient (c=0xa12630, lift=1) at dwl.c:1442 old = 0xa1c0e0 i = 4 unused_lx = 666246284 unused_ly = 0 old_client_type = 0 old_c = 0xa1eef0 old_l = 0x0 #8 0x0000000000417df9 in setmon (c=0xa1eef0, m=0x0, newtags=0) at dwl.c:2326 oldmon = 0x9cde90 #9 0x0000000000419113 in unmapnotify (listener=0xa1efb0, data=0x0) at dwl.c:2725 c = 0xa1eef0 #10 0x00007f0bf422c80c in wl_signal_emit_mutable (signal=, data=0x0) at ../src/wayland-server.c:2241 pos = 0xa1efb0 l = 0xa1efb0 cursor = {link = {prev = 0xa1efb0, next = 0x8af290}, notify = 0x7f0bf422a770 } end = {link = {prev = 0x8af290, next = 0x9fa540}, notify = 0x7f0bf422a770 } #11 0x00007f0bf42b92a4 in unmap_xdg_surface (surface=0x9fa450) at ../types/xdg_shell/wlr_xdg_surface.c:36 __PRETTY_FUNCTION__ = "unmap_xdg_surface" popup = 0x9634f0 popup_tmp = 0xa1b760 configure = 0x7f0bf422b614 Quit Detaching from program: /usr/local/bin/dwl-guile, process 1356 [Inferior 1 (process 1356) detached] ```

sevz17 commented 11 months ago

Maybe @PalanixYT wild guesses are correct (printstatus function??), I can't really tell.

They aren't wild guesses, it's usually the problem when dwl freezes

@sevz17 , I forgot that I'm running dwl-guile on my machines nowadays, so I'll try providing a gdb output for dwl master later.

No need, you just need close the stdin of the child process.

Note: next time please make sure you are running upstream dwl.

yveszoundi commented 11 months ago

@sevz17 , I'm not running any child process per say, except for the status bar itself 'dtao'. My configuration is pretty much vanilla.

I'm trying to reproduce it with the latest upstream dwl (with and then without a status bar program running).

djpohly / dwl