randomly freezing on terminal window resize

[dkuettel]

Issue description

Sometimes when resizing the terminal window, tmux's output freezes. Doesnt update output and doesnt react to keystrokes. Resizing again will make it unfreeze. Usually it registered keystrokes, but didnt render any updates.

reproduce with:

• tmux -v -Ltest -f/dev/null new
• run htop
• start resizing the terminal window
• at some point htop is not updating, especially when you enlarge the window it's easy to see how htop doesn't grow and doesnt redraw
• further resizing will unfreeze at some point

note:

• I'm on fc13e9bc.
• I can reproduce it with gnome-terminal as well as with st (http://st.suckless.org/).
• It happens not only with htop, but there it's easy to see.
• I'm using a tiling window manager (dwm), it's easier to reproduce when resizes are "instantaneous", as in the window manager giving one resize event, but it also happens when resizing with the mouse, just harder to spot, because it rapid-fires resize events where one event makes it freeze and the next one unfreeze.
• the CONTRIBUTING documentation says to use tmux -vv for bug reports, but with -vv it doesnt freeze, only with -v and without any verbose.
• tmux version (tmux -V) = tmux next-3.2 from commit fc13e9bc
• Platform (uname -sp) = Linux x86_64
• $TERM inside (st-256color) and outside (tmux-256color) of tmux (echo $TERM)
• Logs from tmux (tmux kill-server; tmux -vv new) are attached, caveat see above.

tmux-server-25361.log
tmux-client-25359.log

Btw: I remember this happening a few months ago and it got fixed by just moving to the newest commit.

[nicm]

When this happens, does the status line stop redrawing to the new size or does it continue to change size?

[dkuettel]

The status line is also stuck in the old size and does not update the time. I noticed that when I manage to get tmux stuck by resizing the terminal window and I leave it in that state, then also all other sessions on the same server are stuck. And doing tmux ls on that server is also stuck until I resize the window to unstuck it all.

Probably related: a few times it happens when I maximize the terminal window that tmux uses the old smaller width but otherwise works correctly, not frozen. At that point I do not have a second client connected with a smaller terminal width.

[nicm]

Can you build tmux against libevent 2.1.11 and see if you can still reproduce?

[dkuettel]

Building against a recent libevent seems to have fixed it. I haven't encountered any freezes now. Thank you very much.

It was clearly my mistake: The readme does say that a libevent 2.x is required. I don't know how I got to have a libevent 1.x on my system instead. I've had it like that for a long time and never noticed.

After ./configure didn't complain, I thought I got all the dependencies right. I'm not very versed with the automake tools. Would it make sense to require 2.x somewhere here https://github.com/tmux/tmux/blob/master/configure.ac#L143 ?

[nicm]

There have been issues with libevent signal handling in some versions but I forget which. I do use libevent 1.4 regularly and have never seen this, but I don't resize often and if it goes away after a second resize maybe I just didn't notice. Anyway if libevent 2.x fixes if there isn't much point in worrying about it. Maybe you're right and we should set a minimum version in configure, I'll take a look.

[nicm]

Hmm the problem is that OpenBSD still uses libevent 1.4. The signal problems I remember were only with poll/select when libevent uses a separate pipe for signals - on OpenBSD it will use kqueue which doesn't need it. So we only need to reject libevent 1.4 on platforms where kqueue isn't available.

[nicm]

I don't think there is a way to do it sanely, because there isn't a sensible way to get the libevent version if not using pkg-config, I think we will just need to leave it.

Anyway, let me know if you see any further problems. Thanks!

[nicm]

This is probably libevent/libevent@f0ff765 which was fixed in libevent 1.4.15 (I forgot about this completely). Better to use 2.1.x anyway.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.