Redraw randomly hangs until a keypress

[valff]

Using Alacritty (commit 6916537) on Ubuntu 16.04 with X11.

It is better described with the following screencast. Here I'm repeatedly opening and closing tig, so the output should be the same in each iteration. The screen often stays in a partially redrawed state (marked by mouse cursor movement). Then it finishes redraw correctly when I'm pressing a key.

[Haggus]

I have the same exact bug. Ubuntu 16.04 with X11.

However, the interesting thing is this, bug appears only on when working in tmux.
Also, this bug doesn't exist on my Arch desktop (even when I'm using tmux).

[valff]

For me it is the same with and without tmux. I guess it can be hard to debug.

Please guide me how can I help with this, I'm familiar with rust.

[jwilm]

We've had a few isolated reports of this since the issue was originally "fixed". It's to the point I can no longer reproduce, but I am happy to advise you on doing the debugging if you're willing to get your hands dirty.

There are two primary threads in Alacritty: 1. the parser thread, and 2. the render/input thread. The parser thread reads from the pty asynchronously and locks the terminal struct once it's got some data. With lock in hand, the parser runs and updates what is visible on the screen. After the buffer is drained and terminal updated, this thread sends an event to the render/input thread which should trigger a wakeup. This all happens within EventLoop::pty_read.

You might note that the render/input thread is only notified when the terminal dirty flag is not already set. As an initial sanity check, you might try disabling that check and always notify the render thread (this has a performance penalty which is why we don't already do it). At the same time, that might not actually be the problem and just change around timing enough to appear to solve the issue. Thus, this can be used to demonstrate that the dirty flag check is not the problem (would still have the issue), but it cannot conclusively conclude that it is the problem (issue might go away, but for different reason). In this latter case, you'll probably want to start adding some logging about when the render thread is kicked.

The part where this is consumed on the render thread starts in main.rs. The first line in this loop

let mut terminal = processor.process_events(&terminal, display.window());

will usually block and wait for events. Note that further down the loop, there's a check

if terminal.needs_draw() {
    // draw
}

So either this check would be returning false, or control never reaches this point.

Looking at Processor::process_events, this method is either blocking or polling for events based on initial state. Your draw problem ends up with it stuck blocking for events and never waking up, so we'll want to check that out. I would recommend adding some logging in that area. Finally, you might want to add some logging where the Awakened event is handled.

I'm happy to help review the logs you generate or guide you through more of the code. Please let me know how else I can help; I would love to fully squash this bug, and I need help from someone like yourself to do it.

[valff]

@jwilm Thanks for a great guidance! Will find a spare time and start digging.

[koivunej]

I think I might be hit by the same issue and I have stayed on a rather old version of alacritty because of this (24c32dc). I don't think I can spare much effort right now into digging this as well but I can try to see if any fix helps my case. This is on Ubuntu 16.04 based system as well, with an elderly Intel HD 4000, at least judging by the Xorg.log.

[valff]

@jwilm Hey. I made some testing, but didn't figure out the issue. Firstly with debug build the problem is solving. I have an overclocked 4.7ghz cpu, so I guess it is a timing issue, which appears on fast enough cpus.

Also commenting out terminal.needs_draw() also helps, but I believe it is not the root of the issue. I made a debug logging, and everything looks fine, Awakened event is triggered correctly, and causes redraw afterwards.

Looks like the terminal.draw() renders a stale state. How can it be?

Edit: wrong frequency.

[divoxx]

This issue just started happening to me for the first time. I've been using alacritty as my main terminal for about 6 months and haven't seen the problem before, until now.

I was able to narrow down the context in which the problem happen, at least for me. It only happens when using a compositor (happens with both mutter/gnome and compton for me), and when there are multiple Alacritty windows open. It does not happen with composition and just one window.

PS: Deleted my previous messages since they weren't really accurate

[chrisduerr]

Might be related to #1227.

[dominik-zeglen]

It's happening on my i3-gaps + compton machine too. It seems that switching compton backend from glx to xrender helps.

[DrRibosome]

same issue:

• running on ubuntu 16.04
• built from hash 512fc6109182523c50e55ca8729b056442f36823
• happens all the time, even outside of tmux, etc
• on startup, alacritty terminal background is the same as the window behind* the terminal, until I press a key and it redraws
• issue seems to happen once every 10 key strokes or so (pressing enter or control-c)
• clicking on the screen or typing a character seems to cause a redraw whenever it gets behind

[chrisduerr]

I have a hunch that this issue might be solved with #1518, since another similar issue was fixed with it. I've added this issue to the issues which will be automatically closed once that PR is merged.

If anyone is able to reproduce this issue with #1518, please let me know and I'll remove the reference to this issue.

[petobens]

Hi @chrisduerr I tried #1518 with #1403 and I'm still seeing the issue (randomly). No idea what's going on (is it related to the GPU?). This turns Alacritty a bit unusable :( (the only apparent way to force a redraw in my case by opening a new window and send the current (hanged) alacritty window to the back).

@dominik-zeglen the compton change fixes the issue for you?

[chrisduerr]

Huh, I was never able to reproduce this. But thanks for letting me know that #1518 does not fix this. I'll remove the auto-close message from the comments.

[atopia]

Not sure if this is the same issue, but on Arch Linux/X11/awesome, current master does not draw characters until a key press, mouse click or resize. Background color + opacity is drawn fine, but shell prompt only shows up after any of the three. I'll be offline until next Saturday but can help debug this next weekend. I don't recall the same issue on 0.2.0, but I might just not have noticed because the tiling modes cause a resize at startup.

[loewenheim]

I’m experiencing the same issue with i3-gaps and compton. Switching compton to xrender works, but feels a bit sluggish in general.

[chrisduerr]

I'm using i3-gaps and compton myself and I've never run into this issue. Which GPU are you using @loewenheim?

[loewenheim]

Here’s the output of lspci:

00:02.0 VGA compatible controller [0300]: Intel Corporation Skylake GT2 [HD Graphics 520] [8086:1916] (rev 07) (prog-if 00 [VG  controller])
	Subsystem: Lenovo Device [17aa:5053]
	Flags: bus master, fast devsel, latency 0, IRQ 126
	Memory at f0000000 (64-bit, non-prefetchable) [size=16M]
	Memory at e0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at e000 [size=64]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: <access denied>
	Kernel driver in use: i915
	Kernel modules: i915

[Spencer-H]

I'm using i3-gaps with compton on version 0.3.2, this issue appeared when reflow support was added.
Alacritty will stop redrawing until I mouse over it or press a key if I have it highlighted.

[askobara]

I've faced same problem with Gnome on X11, but when I switch my DE to awesomeWM it's disappearing

[cj360]

Also seem to have this issue (I think anyways) I noticed long stretches of code like building a fork of aosp for Android or just playing music with mpd + ncmpcpp the terminal & visualizer will appear to hang but keyboard input or mouse movement will have it immediately redraw and catch up. This is on Arch Linux with Nvidia's vulkan beta drivers 418.52.14 on xorg-server 1.20.5-1.

[gbalke]

I have the same issue on Ubuntu 18.04 running i3 (Intel graphics accelerator). Generally occurs when I'm doing anything that prints lines continuously although I just noticed it with a git commit (froze half way through the print).

[kchibisov]

@gbalke you're observing this one #2217 .

[mooskagh]

Happens to me too. Usually I blamed ssh connection for that, but today it happened twice when running something locally. I don't use tmux or any other terminal multiplexer.

Happens much more frequently on my laptop, where I have ubuntu 14.04.6 LTS with Alacritty v0.2.9, but also happens at my workstation/desktop, where I run arch linux and have 0.3.3-2 installed.

Always happens when long (but not extremely long) output happening and scrolling the screen (like building something or pacman -Syyuu), but maybe it's just because I happen not to press keys while it's happening. (when I type, maybe it would happen too, but it's easy to be unnoticed).

UPD:
This indeed seems to be i3 specific, I also run i3wm.
On the laptop where it happens the most, I believe I don't use any composition manager.

[fcharras]

Happens every 30 seconds or so on my laptop, using arch linux / i3 with Xcompmgr.
edit: the issue happens after i turn off xcompmgr actually, when it's on there's no problem.

[kchibisov]

Could someone try #6175. At least it fixes it for me in vm, since I never had it with anything else.

[spaddex]

@kchibisov, I'm running X11 with tmux and experience the issue mentioned here and in #4362.
Have not experienced the issue since switching over to #6175 (been running it for ~3 days)

[acook]

Can confirm this happens with the latest released version of 0.11.0 but no longer is reproducible with the latest from git 0.12.0-dev (2d27fff7)!

Correction: It still happens, just significantly less often. Puzzling.

It now seems to behave like Kitty, where there will be random pauses and it will catch up on its own, or a keypress will refresh it. But not all keypresses, if there is a gap of time since the last update, the next keypress may not have any effect until a second one occurs.

I don't have any issues with other graphics programs, so it seems there is something about the way terminal programs work. Although I have a theory...

[nobrowser]

Still happens to me with 0.12.2 , on pop-os (based on Ubuntu) 22.04 LTS. I haven't seen it except with tmux as the shell, though I haven't tried very hard. With tmux, every couple of minutes :(

[charlesdaniels]

This is still happening for my on 0.12.2 on pop-os 22.04 as well.

$ alacritty --version
alacritty 0.12.2
$ uname -a
Linux eos 6.5.4-76060504-generic #202309191142~1695998943~22.04~070916d SMP PREEMPT_DYNAMIC Fri S x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/os-release
NAME="Pop!_OS"
VERSION="22.04 LTS"
ID=pop
ID_LIKE="ubuntu debian"
PRETTY_NAME="Pop!_OS 22.04 LTS"
VERSION_ID="22.04"
HOME_URL="https://pop.system76.com"
SUPPORT_URL="https://support.system76.com"
BUG_REPORT_URL="https://github.com/pop-os/pop/issues"
PRIVACY_POLICY_URL="https://system76.com/privacy"
VERSION_CODENAME=jammy
UBUNTU_CODENAME=jammy
LOGO=distributor-logo-pop-os

[borjasanlei]

Same here! This issue should be reopen or at least considered:

$ alacritty --version
alacritty 0.13.0-dev (a58fb39b)

$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.3 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.3 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

[trungda]

Same here! I am running alacritty on tmux.

alacritty --version
alacritty` 0.14.0-dev (caf8c7fc)

cat /etc/os-release
NAME="Pop!_OS"
VERSION="22.04 LTS"
ID=pop
ID_LIKE="ubuntu debian"
PRETTY_NAME="Pop!_OS 22.04 LTS"
VERSION_ID="22.04"
HOME_URL="https://pop.system76.com"
SUPPORT_URL="https://support.system76.com"
BUG_REPORT_URL="https://github.com/pop-os/pop/issues"
PRIVACY_POLICY_URL="https://system76.com/privacy"
VERSION_CODENAME=jammy
UBUNTU_CODENAME=jammy
LOGO=distributor-logo-pop-os

[akyoto]

This issue comes up on Google search, just adding that this happens on my machine as well:

~ alacritty --version
alacritty 0.13.1 (fe2a3c56)

OS: Arch Linux x86_64
DE: GNOME 45.3
GPU: NVIDIA GeForce GTX 1070

[acook]

It seems like the maintainers aren't looking at this thread, it might be time to create a new issue and just link to this one.

[kchibisov]

We're aware of issue with nvidia/llvmpipe on X11, which is likely not our issue, but just how x11 works. there's #7251.

[acook]

Terminals have been working fine on X for decades, and no other programs require a keypress to force a redraw. So I'm confused as to how it's an X11 issue?

[kchibisov]

That's completely irrelevant whether they worked or not. The issue is that one frame on X11 is not being presented to the display for whatever reason when we draw and submit it, so for now the only viable solution would be to draw e.g. 3 times last redraw just to ensure that the frame goes to display.

X11 is just not great when it comes to hardware acceleration, because it was never designed with it in mind, so things break like that is not surprising. Keep in mind that contiguous redraw generally works, because it's contiguous. For now only nvidia and llvmpipe seems to be broken, and intel using legacy xf86-video-intel(shouldn't be used anyway).

[Inky-developer]

I have this issue on my laptop, which uses a AMD Ryzen 7 4700U with Radeon Graphics for hardware acceleration

[xfnty]

For me the issue was caused by mouse.hide_when_typing = true.
I use Artix/Wayland/Sway. I also noticed that when the terminal hangs
after i typed basically any command or pressed enter in nano for example
I could not move the mouse.

So the solution for me was to disable the flag.

Alacritty version is alacritty 0.13.1 (fe2a3c56), got it from pacman.

[kchibisov]

after i typed basically any command or pressed enter in nano for example
I could not move the mouse.

that sounds like a GPU hang to me, maybe you have something in dmesg when such thing happen?

[d-s-a]

For me the issue was caused by mouse.hide_when_typing = true. I use Artix/Wayland/Sway. I also noticed that when the terminal hangs after i typed basically any command or pressed enter in nano for example I could not move the mouse.

So the solution for me was to disable the flag.

Alacritty version is alacritty 0.13.1 (fe2a3c56), got it from pacman.

Turning hide_when_typing off did fix it for me.