Powerline possibly sends garbage characters on resize

[sasq64]

I had a problem with a terminal emulator I am developing for some time with powerline sending garbage characters on stdout if you resize rapidly. Initially I thought it was a bug on my side but after investigating it looks like it comes from powerline, or zsh/powerline in combination.

I log all bytes directly in the terminal, reading from the zsh process, and I see sequences like these;

bd 04 ec 6d fa 07
0b 81 eb fe fc 07
cf 01 de 20 fa 07

embedded among normal ansi sequences. It looks like they may be addresses, so it is potentially a stack array overrun problem.

As I have not been able to reproduce it in other terminal emulators I post this here as a FYI, hoping that someone has an idea why this happens.

[ZyX-I]

Powerline itself does not have any C code aside from the C client (which is too simple and much unlikely having any bugs like this) and also does not care about resizes more then having a “width” argument. With the technology stack used any “stack array overrun” problem most likely comes from (in order, assuming you are using powerline-daemon) your terminal (as it is being developed), zsh, powerline C client (least likely, it only sends arguments and environment variables as-is via a socket, and the only thing which should change at resize is that width argument), powerline ctypes code (stack array overrun resulting in some data sent to a socket is not very likely), CPython, some powerline C dependency (even less likely), C compiler (client C code is really simple).

You may get some more data if you

1. Do eval PS1=$PS1 (also with RPS1 if it is displayed, otherwise it should just be an empty string). This should distinguish cases “zsh or your terminal has a bug” vs “likely it is neither”, less likely if you experience problems when you resize so that powerline does not have to change amount of segments displayed. A bit better emulation of powerline without powerline is PS1="\$(sleep 0.05s ; printf "%s" ${(qqq)${(e)PS1}})".
2. Replace C client with python or shell one (better the second, requires socat) which may be found in client/ directory in this repository. Will increase the time to show prompt (especially Python variant). The “replacement” client must appear as powerline somewhere in $PATH, obviously before regular powerline client. Assuming done 1. with sleep (I would vote for the bug being “zsh caught WINCH while redrawing prompt because of previous WINCH”) this should distinguish between cases “powerline client is responsible for the sequences” vs “powerline client is not responsible”. Note: in case it is zsh timing bug you are more likely to catch it because all replacement clients are slower then C client.
3. Whether it is a bug in powerline ctypes code, CPython or powerline C dependencies may be checked by straceing the daemon process. Do not check what it writes to stdout/stderr, it should write replies to a socket. If it is not an array overrun or something like this it may be a powerline bug in places other then powerline ctypes code, but Python provides memory access safety guarantees and any array overruns in the rest of powerline code are CPython bugs.
4. If straceing caught something the biggest ctypes-using blob is notify code. That may be disabled in ~/.config/powerline/config.json by making it contain {"common": {"watcher": "stat"}}. The second thing other then tests which uses ctypes is powerline/lib/monotonic.py and you can’t disable it without editing source code or upgrading to Python-3.4 or higher.
5. Any dependency used by powerline which has C extensions may be disabled by uninstalling it: powerline has no required dependencies other then CPython. Though default shell theme should not use code from any of them.

Do not forget to restart daemon after changing configuration or uninstalling a dependency. This is not required for other tests.

[sasq64]

Thank you, that was some seriously detailed information.

Using those tricks I have now figured out that it is a bug in zshell 5.2, which is the one that still comes preinstalled in OSX. Using 5.3 from brew eliminates the problem.

I also managed to see the issue in another Terminal Emulator in the form of random bell sounds (the 0x07 characters in that binary dump).