Alacritty: Redraw randomly hangs until a keypress

[valff]

Using Alacritty (commit 6916537858d12e02478d618339d1b9f0e73a677a) 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.

[mderrien29]

Getting this issue on 0.3.3 too, with things like the npm package https://www.npmjs.com/package/concurrently or nvim being the biggest culprits.

Maybe multithread related ?

[sagis-tikal]

Getting this issue on 0.3.3 too, with things like the npm package https://www.npmjs.com/package/concurrently or nvim being the biggest culprits.

Maybe multithread related ?

I wouldn't imagine it's a part of it - to me it also happens when I run the command 'watch -n0.1 date' or tail -f /some/file
P.S. I'm using Manjaro Linux with i3wm under Virtual Box.

[mooskagh]

I can also confirm that it happens during streaming console output (cat filename or git pull or make to build something), it's not specific to being full-screen (like vim or tmux) or running multithread in some way.

[chrisduerr]

The issue you're looking for is https://github.com/jwilm/alacritty/issues/2217. Please don't spam either of them with +1's, since that will likely just burry useful information. If there's additional information required, I'll let you know, thanks.

[andys8]

I'm looking forward to glutin eventloop 2.0 which is actively worked on and will eventually fix the issue. But until then it drives me nuts. It happens a lot and I constantly press random keys, because I'm afraid the terminal isn't updating.

Is there a workaround to avoid having to switch to a different terminal emulator? E.g firing events constantly, disable optimization or to use an older version of alacritty or https://github.com/chrisduerr/alacritty/commit/1e8e9046cec57b7f08748cacbbed17ae9170ae66?

[chrisduerr]

It would be possible to use an older version of Alacritty until the issue is resolved.

There are also some patches in the archlinux repository which downgrade the glutin version, applying those might solve the issue though their focus seems to be on resolving transparency problems.

I would also expect the evenloop 2.0 pull request to be usable soon on Linux. My plan is to resolve the remaining issues in Alacritty within this week, however that does not mean that there won't be any remaining issues upstream. However on macOS this won't help at all.

So those are the main options for now. The next Alacritty will definitely release with this fixed, hopefully relatively soon once the upstream macOS issues are resolved.

[inglor]

I'm using the pr2438 patched on top of 5cf77bf250712bf2630322f92c1025baa364922e (master) without issues (so far) at archlinux (locally build).

[chrisduerr]

I think I can reproduce this issue with the evlp2 branch. So this needs more investigation.

[andersevenrud]

I immediately updated now that I saw #2438 was merged. This seems to have solved all of the issues I had relating to this (and so much more) :heart_eyes:

[leosunmo]

This is great stuff! I would greatly appreciate a new release with this fix in it as I can finally recommend Alacritty for colleagues and projects!

[atopia]

As of 729eef0c, on my system (Arch Linux, X11, awesome WM ), a visual bell stays "on" until some interaction with the window is performed (such as moving the mouse):
$ sleep 1; echo '\a'

[sagis-tikal]

I've tested https://github.com/jwilm/alacritty/commit/729eef0c933831bccfeac6a355bdb410787fbe5f as well, seems like the issue was solved in it's entirety, no bell issues too.

Thanks for the amazing support!!! 💯

[originalsouth]

As of 729eef0, on my system (Arch Linux, X11, awesome WM ), a visual bell stays "on" until some interaction with the window is performed (such as moving the mouse):
$ sleep 1; echo '\a'

Can confirm this behavior for post 729eef0 on archlinux.

[ratorx]

I tried alacritty 0.3.3 and a75e9493449d90b54a140b76f6a96b684784a059 (Arch Linux; i3-gaps) and the issue persisted for me. I also tried termite and ran into the issue there as well. However, I can't reliably reproduce it (I just spam commands into the terminal until it eventually happens. The most reliable trigger seems to be trying to run commands with slightly delayed output such as sudo).

Running compton with vsync = false seems to fix it for me (as an alternative to using xrender backend).

[givensnickel]

If it's any help, I have found that with multiple windows open they all freeze at the same time and a keypress in any of them will unfreeze them all.

I'm on Arch, with xfce for both desktop and wm.

[Dzordzu]

Note that (as of today) an arch package alacritty-git is out of date (v 0.3.3). This version still suffers from this issue.
What's more (as it has been already said) 729eef0 solved an issue. So it should be closed

[chrisduerr]

@Dzordzu That's a separate issue.

[FFY00]

@Dzordzu the package is not outdated. In fact, there's no package, there is a PKGBUILD (package build script). The PKGBUILD will fetch and build the last commit. There's nothing outdated.

[Dzordzu]

Fact - this is PKGBUILD script. But it doesn't matter, most of the community will name it "package".

And in the theory alacritty-git SHOULD do this (or build alacritty by tag name). In practise there is a little change

[FFY00]

Fact - this is PKGBUILD script. But it doesn't matter, most of the community will name it "package".

Yes, I just clarified it to explain the seccond part.

And in the theory alacritty-git SHOULD do this (or build alacritty by tag name). In practise there is a little change

What little change? That comment is not related at all. The current PKGBUILD is fetching the last commit. Everything works as expected. I don't understand what you are trying to argue here.

[quininer]

@Dzordzu I don't think git package must follow tag version, if you want, you can use community package.

[Dzordzu]

My bad. The problem with package versioning on my machine (that lasted for almost a half a year from now) was on my side. I'm sorry for interrupting.

[chrisduerr]

I'd be curious if anyone was ever able to reproduce this with Wayland or macOS. It seems like this issue is exclusive to X11?

[jtroo]

Just want to add something that may be useful.

I was using the Debian distribution which was 0.2.9 and was reproducing the issue in X11 - Debian 10 + xfce. Tested in Weston (Wayland) in otherwise the same environment and the issue does not occur.

However, tried compiling master ( f48c43f ) and the issue no longer occurred in X11.

[FergusFettes]

Also having this issue on Ubuntu 20.04, running regolith (i3). Tried both building from source and installing with cargo to no avail.

However on the same computer it works when using the standard ubuntu gnome desktop. So seems in my case to be due to i3. I'll dig further and report back if I find the cause.

[leosunmo]

@FergusFettes Try disabling Compton.

killall compton

[fcharras]

Compton has a fork known has picom, switching to picom fixed the bug for me.

https://wiki.archlinux.org/index.php/Picom
https://github.com/yshui/picom