Running ncurses program that uses funky glyphs in alacritty freezes sway

[cshapeshifter]

Maybe solving this issue can help with some of the "random freeze" issues since it's completely reproducible, at least for me.

UPDATE: It turns out that simply running cat /dev/urandom is enough to reproduce the problem.

I dug up an old little program I wrote years ago (adapted from an existing one). It emulates the "raining text" from the movie "The Matrix" in a terminal. C source Save your work before trying it, because it may freeze your session. Compile by running gcc cmatrixreloaded.c -lncurses -o cmatrixreloaded, then run ./cmatrixreloaded in alacritty. Press any key to stop the program.

If I run it in a small alacritty window, it works fine. However, if I run it in a somewhat larger window (filling at least 50% of my 3840x2400 screen), it runs for just a few frames and then sway itself freezes up. The screen is frozen and I can't move the mouse cursor anymore.

If I do nothing, the screen may flicker a few times and the swaybg background image may appear through the glyphs. I managed to run grim in a while loop to capture this:

I can still switch to a different TTY, although that takes a few seconds, much longer than usual. If I switch back to sway, the screen will either be black (and now I can move the mouse cursor, but do nothing else), or it will be in a grayish flicker. Either way, I have to kill sway.

Things I tried

• I tried copying some of the glyphs into a text file and just using cat inside alacritty, but that doesn't reproduce the issue. It may be something about ncurses' special terminal instructions for font and color rendering...

• If I run this program in urxvt or alacritty via XWayland or in gnome-terminal (native Wayland), no such problem occurs and the program runs just fine, even fullscreen.

• If I run this program in alacritty (Wayland) inside weston, there's no problem.

System

This is a Dell XPS 2-in-1 7390 with Intel Ice Lake / Iris Plus Graphics G7

• Archlinux 5.6.14-arch1-1
• alacritty 0.4.3
• sway 1.4-f8dd7df1 built from git today
• wlroots 0.10.0.r171.g8f28f5b2 built from git today sway -d 2> ~/sway.log and sway config I think the freeze occurs somewhere around second 16.

Since sway doesn't crash but freezes, I don't have a stack trace.

[emersion]

Maybe alacritty submits too many GPU jobs and Sway can't render anymore. If that's the issue, should be fixed when we have proper explicit sync support.

[kchibisov]

I can't repro, but I can't even get the similar output your seeing from yout program. For me those are all ascii no matter what. What version of alacritty was that? How I should run your program. Do I need something else to make it output unicode? But in general if those glyphs are a problem, you can try cat /dev/urandom.

[cshapeshifter]

If your terminal font supports UTF8 it should work. You could try running it with -f.

But in any case, you're totally right, simply running cat /dev/urandom is enough to trigger the issue!

It manifests a bit differently. Again, it doesn't cause problems in a smaller alacritty window, up to about 50% screen coverage, but if I make it larger than that, the problem manifests: alacritty output is frozen, but I can still move the mouse cursor. If I do so, the entire terminal flickers for every pixel that I move the cursor. Again, I can only kill sway to recover.

[simon-auch]

For me, running cat /dev/urandom in alacritty does not freeze sway, but works as intended. At least while not in fullscreen. If I switch to fullscreen it suddenly appears to corrupt the framebuffer (still black and white, but the "glyphs" are all over the place). Absurdly enough I can't take a screenshot of it, since the moment grim starts it look fine and goes back to a corrupted state after taking the screenshot....

Photo made using my phone..

[simoncarpinter]

Is anyone else reporting this problem using that hardware? I've got the exact same hardware and experience similar issues; my AMDGPU-based desktop doesn't manifest them. It could be related to framebuffer size (this is my only HiDPI display), but I've had to do things like run Sway with WLR_DRM_NO_ATOMIC=1 and WLR_DRM_NO_MODIFIERS=1 to keep Sway from randomly corrupting the entire screen (usually triggered when adding/removing external displays).

I'm not educated enough in window managers and display rendering technology to understand what the cause is, but I have a sneaking suspicion there's an underlying bug in the Ice Lake graphics stack.

[simon-auch]

Ah sorry, I forgot to mention my configuration: CPU: skylake i5 GPU: and rx 5700 xt OS: archlinux Monitor resolution: 3840x1600

Using the amdgpu driver, if that helps.