Server exited unexpectedly using neovim 0.10.0 over SSH in terminals that support sixel

[prurigro]

Issue description

Running tmux in Alacritty then SSHing into a client and running neovim 0.10.0 will crash the tmux server.

• Running tmux in urxvt and doing the same does not cause the issue.
• SSHing into a server with neovim 0.9.5 and doing the same does not cause the issue.
• I've tested both with my personal tmux config as well as vanilla (logs below are using my personal config, let me know if you need vanilla)

In case this was due to the new osc52 support for copy/paste, I tried disabling osc52 in the alacritty config but there was no difference. I also attempted to prevent osc52 copy/paste in neovim by forcing unnamedplus (which the documentation says prevents the feature from loading) but still hit the issue.

Describe the problem and the steps to reproduce:

1. Start tmux in Alacritty
2. SSH into a box with neovim 0.10
3. Run nvim -u NORC (to load without any config)
4. Observe [server exited unexpectedly]

Required information

Please provide the following information:

• tmux version: 3.4 (from the Archlinux repos)
• Platform: Linux unknown (Archlinux)
• Inside tmux: tmux-256color -- Outside tmux: alacritty
• Logs:
  tmux-client-607371.log
  tmux-out-607375.log
  tmux-server-607375.log

Let me know if you need additional information and I'd be happy to provide it. Also, thanks for maintaining tmux :)

[Cnly]

That was fast! I was about to submit the same bug report when I saw this, so I'll add my report here. My terminal emulator is iTerm2 Build 3.5.0beta26.

My steps to reproduce

1. tmux -vv -f /dev/null -L test new
2. ssh onto a remote machine with neovim 0.10 (NVIM v0.10.0 from linuxbrew)
3. Start neovim with no custom config: nvim -u NONE

I've tested this with both the following setups:

• (to test on a mac) tmux on my mac → ssh onto linux server A → start nvim → local tmux crashes
• (to test on a linux) ssh onto linux server J → start tmux → ssh onto linux server A → start nvim → tmux on server J crashes

Required information

• tmux version (tmux -V): tmux 3.4 on both my mac and linux server J
• Platform (uname -sp). Darwin arm and Linux x86_64
• $TERM inside and outside of tmux (echo $TERM).
  • on my mac: screen-256color inside and xterm-256color outside
  • on linux server J: tmux-256color inside and xterm-256color outside

The last few lines of tmux server logs look like this:

1715960621.245436 screen_redraw_draw_pane: /dev/ttys023 %0 line 0,52 at 0,52, width 92
1715960621.245444 tty_draw_line: px=0 py=52 nx=92 atx=0 aty=52
1715960621.245451 tty_draw_line: defaults: fg=8, bg=8
1715960621.245458 tty_draw_line: 92 to end of line (0 cleared)
1715960621.245465 tty_clear_line: /dev/ttys023, 92 at 0,52
1715960621.245471 /dev/ttys023: \r
1715960621.245484 /dev/ttys023: \n
1715960621.245496 /dev/ttys023: \033[K
1715960621.245510 tty_cmd_sixelimage: image is 1x1
1715960621.245518 tty_cmd_sixelimage: clamping to 0,0-1,1
1715960621.245549 fatal: xcalloc: zero size

Looks like it's related to sixel?

[prurigro]

True, I should have mentioned that I patched sixel support into the latest Alacritty release. It would be odd if neovim was triggering a sixel-related bug on that note.

[Cnly]

Found this issue following the sixel lead: neovim/neovim#28082. Unfortunately iTerm2 seems to have no way to disable sixel so I can't test without it...

[nicm]

Does this still happen with master?

[prurigro]

@nicm: I just tested in master and the issue does not occur there

[nicm]

Great stuff. I expect it was fixed by aa17f0e.

[marcomayer]

Nice, will there be a new release soon? 👀

[jby]

I just came here to report the same thing, with iTerm, but apparently it's known already - nice.
Awaiting a new release so I can go back to using iTerm

[Cnly]

@jby for now a workaround would be brew install tmux --HEAD

[jby]

@jby for now a workaround would be brew install tmux --HEAD

It still happens with tmux next-3.5

[jby]

Oh, and related to the OP - for me there's no problem in Alacritty, even with 3.4...

[jby]

@jby for now a workaround would be brew install tmux --HEAD

It still happens with tmux next-3.5

Hmm, it didn't crash on a second try, so I'm hopeful...

[prurigro]

@jby the reason it was happening for me with alacritty is because I have sixel support patched in. I've edited the title so it describes the issue better in case others are looking here in the future.

Try patching aa17f0e into 3.4 and the issue should disappear.

[cynicaljoy]

Hmm, it didn't crash on a second try, so I'm hopeful...

witnessed the same behavior. first time launching neovim I saw [server exited unexpectedly] (though tmux didn't wholesale crash this time), launched neovim again and it's running seemingly fine now.

[MarkusZoppelt]

Also happening to me inside of WezTerm with tmux 3.4 + nvim 0.10.0 over ssh on macOS.
Using Alacritty instead of WezTerm works.

[lennartack]

This was also happening for me locally when $TMUX is not set, for example after running su -. So a workaround could be to make sure that TMUX is exported.

[ryad-eldajani]

Observe the same behavior when opening a file in neovim via sudo in a tmux session:

$ tmux
$ touch file.txt
$ sudo nvim file.txt
[server exited unexpectedly]

However, can confirm that the workaround suggested by @lennartack does not crash tmux:

$ tmux
$ sudo -E TMUX=$TMUX nvim file.txt

[sainttttt]

Yeah setting TMUX to anything like export TMUX=meow on the remote machine that I'm ssh'ing into stops the crash from happening. Without it, it still crashes for me on tmux-HEAD on macOS

[blacklight]

export TMUX=foobar on the remote machine does the trick, but it's still a very dirty workaround. I'm still in the situation where i SSH into a box, type nvim forgetting to export TMUX, and my whole session crashes.

Are there any plans for a new tmux release that includes the fix? The latest release was made in February and the version that comes on Arch and any derived distros is currently impacted.

[sainttttt]

So I'm having another issue with neovim and TMUX. If on my host machine I run tmux, and ssh into a server, and then on that remote machine I start a tmux instance (nested tmux) and open vim in there, it crashes everything (crashes my host machine tmux instance). I have $TMUX set on both remote and host machines. Latest nvim running on remote machine and latest TMUX on both host and remote machines. Any idea how to get around this?

Thanks!

[blacklight]

@sainttttt setting TMUX on the remote machine is a workaround that gets things to work in case of single tmux sessions, but I'm not sure how to get it to work with nested sessions, since each will have its own TMUX variable.

I think that nested tmux sessions are not advised in general, and the crash around the remote neovim session may just be one of the many issues you may encounter.

Maybe you could try another non-conflicting terminal multiplexer like screen on the remote machine?

[sainttttt]

@blacklight Thanks for the reply! Actually I noticed that my host tmux was not on HEAD (it was on 3.4). Upgrading it to HEAD fixed the nested issue! I did test out doing nested zellij instances and it worked, however I can't stand zellij as it has a bunch of UI clutter etc, and would have to figure out how to configure it to be more minimal like tmux. Yeah screen is an option I guess as a last resort, but I'm glad it's working now atm. Thanks!

[ChristophSonnleitner]

The TMUX=meow fix worked for me, but caused that clipboard in neovim did not work anymore.
What worked for was opening another tmux session on the server I ssh-ed into (one tmux session on the client, one tmux-session on the server). After that nvim didn't crash anymore and I could use the clipboard still (using wezterm, if relevant)

[lennartack]

@ChristophSonnleitner instead of TMUX=meow you could try to set it to the value it has locally within tmux.