Garbled ANSI escape sequences displayed when running inside tmux

[awaken233]

lnav version

v0.13.2

Environment

• OS: macOS 13.7.1 (Build 22H221)
• Shell: zsh 5.9 (x86_64-apple-darwin22.0)
• tmux: 3.6a
• TERM: screen-256color

tmux config

# Change the default $TERM to tmux-256color
set -g default-terminal "tmux-256color"

Describe the bug

When opening log files inside tmux, lnav displays garbled ANSI escape sequences instead of rendering colors properly. The escape sequences like rgb:0000/afaf/d7d7/8787/d7d7/5f5f\[d7d7/d7d7/8787\\ are shown as raw text in the interface.

To Reproduce

1. Start a tmux session
2. Open a log file with lnav <logfile>
3. Observe the garbled escape sequences in the display (see screenshot)

Screenshot

[telans]

Likewise when opening a log file over ssh.

[tstack]

What terminal are you using?

[awaken233]

What terminal are you using?

Sorry, forgot to write that. I'm using iterm2.

[tstack]

Unfortunately, this is a timing issue that I have trouble replicating on my own machines. I'll keep an eye out, but it's really difficult for me to fix unless I can find a way to reliably reproduce it.

[telans]

Could you please elaborate on what you mean by timing issue?
This happens to me when opening any file actually, even lnav <(echo "Hello World!"). I'm using Konsole. I've attached the debug log:

lnav_debug.log

[tstack]

Could you please elaborate on what you mean by timing issue?

The TUI library lnav uses is querying the terminal for its capabilities. There's a lot of information coming back from the terminal (e.g. color palette) and depending on the timing of when things are sent by the terminal and read by the library, there can be a glitch that causes problems like this. I have previously fixed a couple of issues related to this. But, I haven't been able to reliably replicate issues, so haven't been able to fix them.

[henrebotha]

This doesn't only happen in Tmux. If I run it from a non-Tmux terminal with TERM=xterm-16color, the same thing happens.

The moment I run it with TERM=xterm-256color, everything is fine.

This is in iTerm.

[awaken233]

Hello, maintainer @tstack ,I would like to ask what mac version you are using? What terminal? I think I should upgrade my system, my system is too old, this time I use Terminal , iterm2, Ghostty, Kitty, all have occasional problems with the escape of sequences.

[oats4goats]

I can reliably reproduce this issue in my setup. Here are the specific conditions:

• Terminal: Alacritty (latest version)
• Inside tmux with default-terminal "tmux-256color"
• Terminal feature: set -as terminal-features ',alacritty:extkeys', set -as terminal-features ",alacritty:RGB"
• Issue appears every single time lnav starts in tmux
• Never occurs in plain Alacritty (without tmux)

Exact error displayed:

SQL error: near "50": syntax error
;50;rgb:afaf/d7d7/8787\

I'm available to test / provide strace

[tstack]

@oats4goats Are you on linux or macos? Trying Alacritty/tmux on macos, the failure showed up on a couple runs, but I can't reliably get it to fail.

[oats4goats]

Hey @tstack,

Thanks for your answer! I run Arch Linux (6.12.61-1-lts), alacritty 0.16.1 (42f49eeb), tmux 3.6a.

Hope it helps

[tstack]

I've found an issue in lnav/notcurses and pushed a change to try and fix it. If you can try one of the binaries attached to the latest run of this workflow and report back, that would be helpful.

However, when testing with tmux 3.6a, there still seems to be a problem and it kinda seems like a bug in tmux. When I dump the data directly read from stdin to a file, it looks like tmux is not sending full escape sequences in some cases. The case I am able to reproduce is the palette colors for index 38 are getting messed up. Here's a hexdump of a capture where that happens:

000003f0  30 2f 61 66 61 66 2f 38  37 38 37 1b 5c 1b 5d 34  |0/afaf/8787.\.]4|
00000400  3b 33 37 3b 72 67 62 3a  30 30 30 30 2f 61 66 61  |;37;rgb:0000/afa|
00000410  66 2f 61 66 61 66 1b 5c  1b 5d 34 3b 33 38 1b 5d  |f/afaf.\.]4;38.]|
00000420  34 3b 33 39 3b 72 67 62  3a 30 30 30 30 2f 61 66  |4;39;rgb:0000/af|
00000430  61 66 2f 66 66 66 66 1b  5c 1b 5d 34 3b 34 30 3b  |af/ffff.\.]4;40;|

The important part is the middle line where index 38's sequence is truncated. There should be a ;rgb after the 38, but it skips to the next index. There might be a bug in how I am dumping the data, but I kinda doubt it.

[tstack]

Based on updates to tmux/tmux#4749, there does seem to be a tmux bug.