foot window freezes until keybinding is pressed

[NikitaIvanovV]

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]

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]

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:

dwl/dwl.c

Line 1890 in 797e0c7

if (!wlr_scene_output_commit(m->scene_output))

[yveszoundi]

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]

Found these issues:

swaywm/sway#7519
swaywm/wlroots#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]

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]

@NikitaIvanovV can you check #423?

[NikitaIvanovV]

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]

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

[sevz17]

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]

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]

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]

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]

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]

@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]

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]

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=<optimized out>, data=0x0) at ../src/wayland-server.c:2241
        pos = 0xa1efb0
        l = 0xa1efb0
        cursor = {link = {prev = 0xa1efb0, next = 0x8af290}, notify = 0x7f0bf422a770 <handle_noop>}
        end = {link = {prev = 0x8af290, next = 0x9fa540}, notify = 0x7f0bf422a770 <handle_noop>}
#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 <wl_resource_instance_of+20>
Quit
Detaching from program: /usr/local/bin/dwl-guile, process 1356
[Inferior 1 (process 1356) detached]

[sevz17]

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]

@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).