Giters

aserowy / tmux.nvim

tmux integration for nvim features pane movement and resizing from within nvim.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

tmux.nvim copy_sync related crash

arminveres opened this issue · comments

commented

Hi there,
I am using the newest version of this plugin, with Neovim on nightly, and for the past few weeks, I have been experiencing a crash of this plugin while inside Neovim. It manifests after around 10-15 minutes of being open.

     4 stack traceback:
     5 >       [C]: in function 'assert'
     6 >       ...ocal/share/nvim/lazy/tmux.nvim/lua/tmux/wrapper/tmux.lua:27: in function 'execute'
     7 >       ...ocal/share/nvim/lazy/tmux.nvim/lua/tmux/wrapper/tmux.lua:70: in function 'get_buffer_names'
     8 >       ...veres/.local/share/nvim/lazy/tmux.nvim/lua/tmux/copy.lua:29: in function <...veres/.local/share/nvim/lazy/tmux.nvim/lua/tmux/copy.lua:20>
     9 07:36:18 PM msg_show ...ocal/share/nvim/lazy/tmux.nvim/lua/tmux/wrapper/tmux.lua:27: unable to execute: [ tmux -S /tmp/tmux-1000/default  list-buffers -F "#{buffer_name}" ]

UPDATE:

Tmux version: 3.3a-7.20230918gitb202a2f.fc39
Evidently, I am using Fedora Workstation 39.

Additionally, I am getting an error: Failed to start process: Too many open files for xclip or for e.g., zsh when wanting to open a terminal.

commented

Was there a tmux update as well?

Can you please try to execute the listed call after the plugin crashed? I suspect, this behavior is caused by tmux because the assert checks if the call succeded.

commented

Hi, sure, the output is seen below. I don't know about any intermediate update, but even with copy_sync = { enable = false } this still happens, but with a different stack traceback:

stack traceback:
     1 >       [C]: in function 'assert'
   104 >       ...ocal/share/nvim/lazy/tmux.nvim/lua/tmux/wrapper/tmux.lua:27: in function 'execute'
     1 >       ...ocal/share/nvim/lazy/tmux.nvim/lua/tmux/wrapper/tmux.lua:89: in function 'is_zoomed'
     2 >       ...are/nvim/lazy/tmux.nvim/lua/tmux/navigation/navigate.lua:19: in function 'has_tmux_target'
     3 >       ...are/nvim/lazy/tmux.nvim/lua/tmux/navigation/navigate.lua:32: in function 'to'
     4 >       ...l/share/nvim/lazy/tmux.nvim/lua/tmux/navigation/init.lua:22: in function 'move_bottom'
     5 >       [string ":lua"]:1: in main chunk

I updated the tmux version in my post above.

buffer636
buffer635
buffer634
buffer633
buffer632
buffer631
buffer630
buffer629
buffer628
buffer627
buffer626
buffer625
buffer624
buffer623
buffer622
buffer621
buffer620
buffer619
buffer618
buffer617
buffer616
buffer615
buffer614
buffer613
buffer612
buffer611
buffer610
buffer609
buffer608
buffer607
buffer606
buffer605
buffer604
buffer603
buffer602
buffer601
buffer600
buffer599
buffer598
buffer597
buffer596
buffer595
buffer594
buffer593
buffer592
buffer591
buffer590
buffer589
buffer588
buffer587
commented

Heho,

sry for the late response. It seems the call against tmux fails/times out. Because the error occurs in the assert. The plugin itself is not crashing/bugging out.

Since im not actively dev the plugin anymore im still maintaining it. I would be glad if you can debug and pr a fix.

Kind regards
Alexander

commented

Hi @aserowy, no worries, in the meantime I found out, that some change in Fedora 39 probably reduced the user limit of open files, so the crash has nothing to do with your plugin! Sorry for the confusion and thanks for the plugin

SOLUTION:
Globally update the limit of open files in sudoedit /etc/security/limits.conf by appending this line:

* soft nofile 8192

Which was originally 1024.

commented

Nice that you found a solution! It was a nice experience to write even if im not using it anymore. Neovim is <3 :D