Closed bunyk closed 3 years ago
Hello @bunyk and thanks for the information. This is really unexpected because the hide function of the grids must only be called when multigrid enabled. And neoray doesn't call this function itself. This is most probably neovim issue. But I will look an try to reproduce when I find time.
This morning it happened after I tried to switch the tab with gt
in normal mode. The only difference I noticed was this part of the logs:
...
[TRACE] [NEORAY] Bold: UbuntuMono-B.ttf
[TRACE] [NVIM] Neovim child process closed.
[DEBUG] [NEORAY] Window destroyed.
[DEBUG] [NEORAY] Glfw terminated.
[DEBUG] [PERFORMANCE] CreateWindow Calls: 1 Time: 134.902162ms
...
Previously it had also [WARNING] [NVIM] Failed to close neovim child process: signal: killed
So maybe it indeed is some nvim bug that causes it exits unexpectedly. I tried to reproduce by killing nvim process while neoray is running, but it exited normally without any panics.
Stupid question from someone who does not know yet what is grid or multigrid. Are we allowed to call main.win_hide
, after we logged [DEBUG] [NEORAY] Window destroyed.
? I would assume that after such a log message there is nothing more to hide. :) Maybe it's some concurrency bug here?
By the way, is there any way to see logs of nvim process? Maybe they should point to what is wrong with nvim
, if there is bug there.
I maybe will try to work in console nvim today, and see if the same happens.
Are we allowed to call main.win_hide, after we logged [DEBUG] [NEORAY] Window destroyed.
No you can't. And neoay doesn't call before or after it. The window destroy function is deferred and always be called whether program panics or exits successfully. The actual panic is happening before the 'Neovim child process closed' log.
By the way, is there any way to see logs of nvim process?
Yes, you can. Start neoray with -V[N][filename] option. This will passed to neovim and neovim starts to log the filename. Example: neoray --verbose -V9nvim.log This creates both neoray and neovims debug output in two different files.
I maybe will try to work in console nvim today, and see if the same happens.
This may not happen in console because actual issue is about External UI. Neovim needs an ui rpc connection to call hide().
I couldn't reproduce with Windows 10. Maybe this is a linux only issue of the neovim. But we need more information to say 'this is a neovim issue'.
So, I was running ./bin/neoray_debug --verbose -V9nvim.log
, and it crashed when I tried to do :tabe ~/.config/nvim/init.vim
, while being in the tab with some go code. This is the end of nvim.log
:
Executing BufReadPost Autocommands for "*"
autocommand call s:Autocmd('BufCreate', +expand('<abuf>'))
Executing BufReadPost Autocommands for "*"
autocommand call FugitiveDetect(expand('<amatch>:p'))
Executing BufEnter Autocommands for "*"
autocommand call s:Autocmd('BufEnter', +expand('<abuf>'))
Executing BufEnter Autocommands for "*"
autocommand sil call s:LocalBrowse(expand("<amatch>"))
Executing BufWinEnter Autocommands for "*"
autocommand call s:Autocmd('BufWinEnter', +expand('<abuf>'), win_getid())
Executing CursorMoved Autocommands for "*"
autocommand call coc#float#nvim_refresh_scrollbar(win_getid())
autocommand call s:Autocmd('CursorMoved', +expand('<abuf>'), [line('.'), col('.')])
Executing CursorMoved Autocommands for "*"
autocommand call s:Highlight_Matching_Pair()
Executing WinClosed Autocommands for "*"
autocommand call coc#float#close_related(+expand('<afile>'))
autocommand call s:Autocmd('WinClosed', +expand('<afile>'))
Executing BufWinLeave Autocommands for "*"
autocommand call s:Autocmd('BufWinLeave', +expand('<abuf>'), bufwinid(+expand('<abuf>')))
Executing BufHidden Autocommands for "*"
autocommand call s:Autocmd('BufHidden', +expand('<abuf>'))
Not sure what that means, I have not much experience in VimScript.
Are there any error log in the log file? If not this may not be a neovim issue or there is a segfault in neovim which can not be printed. I can add a simple check to code and prevent neoray from crash, but this will not fix the issue, also even hide it. But I don't have any other choises. Thanks for all information.
No, nothing that looks like error in log file.
I can add a simple check to code and prevent neoray from crash, but this will not fix the issue, also even hide it.
I added following check myself:
func (gridManager *GridManager) hide(id int) {
grid := gridManager.grids[id]
+ if grid == nil {
+ log.Fatalf("Called hide(%d) for nil grid. gridManager.grids: %#v", id, gridManager.grids)
+ }
grid.hidden = true
And after working for some time got:
2021/09/02 23:44:21 Called hide(286) for nil grid. gridManager.grids: map[int]*main.Grid{1:(*main.Grid)(0xc0000692c0)}
So, something tries to hide grid with id that does not exist. While there is one grid in grids. I could add more checks and logs, but not yet know where to look.
I believe I know the reproduction steps now. It happens when there is some hint displayed, like linter error. For example something like this, coming either from 'neoclide/coc.nvim', or 'fatih/vim-go':
If I see such popup, and then switch to or open another tab - this crash happens. Because it calls hide
with some id > 1, while in grids map there is only id == 1.
Maybe you should open an issue on neovim. The neovim itself must not sent this event even when called from a plugin without multigrid is on. This is not a plugin's responsibility.
Opened issue here: https://github.com/neovim/neovim/issues/15589
Current patch fixes crashes, errors are logged. And it's possible to avoid errors by starting with --multigrid
.
What I understand from the issue, neoray always needs to check multigrid events. I will add checks for both is multigrid enabled and is grid id valid for every multigrid event soon.
I'm not sure if https://github.com/neovim/neovim/issues/15589 is still a bug. Should I maybe close it if there are no expected actions from nvim devs?
Dont close it, sometimes other devs are working on such issues. For now we will hardcode the issue.
Please complete the following information:
Steps to reproduce Not yet sure exactly, sorry. Maybe logs would help.
Two times this happened when I was trying to open new file in another tab (
:tabe ...
), but I tried it again, it did not happened, so there should be something else in play here.Your neoray config in init.vim
Crash log if available (may be generated by neoray after crash)