-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Random crash on sudden navigation #112
Comments
This looks like an annoying enough bug I'll try to take a look at this asap, I'm a little surprised i haven't run into this one myself owo |
Ok - this is weird, I think I might need to refresh myself on how to get neovim to dump more information because I'm fairly sure that input events are never something that should fail (unless this behavior has changed in neovim at some point?). |
I think for the time being I might just make this not panic - dropping a key press is probably preferable to a panic (even though in theory we aren't supposed to be hitting this code, bugs are always possible) |
Fixes #112, hopefully. My assumption here now is that because of the GTK+ bug causing the popup menu to close pre-emptively due to popup menu ownership changes - we may also be getting invalid coordinates when this happens, resulting in nvim being upset. So, let's try fixing this.
Fixes #112, hopefully. My assumption here now is that because of the GTK+ bug causing the popup menu to close pre-emptively due to popup menu ownership changes - we may also be getting invalid coordinates when this happens, resulting in nvim being upset. So, let's try fixing this.
Fixes #112, hopefully. My assumption here now is that because of the GTK+ bug causing the popup menu to close pre-emptively due to popup menu ownership changes - we may also be getting invalid coordinates when this happens, resulting in nvim being upset. So, let's try fixing this.
The last fix didn't really seem to make any difference, so I've made some changes so that instead of doing the nvim_set_pum_bounds call asynchronously we do it synchronously. I think this one might actually work, since I've been running this for a few weeks now and haven't had neovim-gtk crash yet.
Describe the bug
Having a lot of opened files in tabs (my current setup involves 45 files in tabs, but it started happening some point before), most of the files having the extra processing of LSP servers running on them; when navigating one file, up-and-down, in a fast fashion (that is scrolling a file of 500+ lines instead of jumping to a specific line directly) makes the GTK-UI crash.
The crash is somehow located around
nvim/ext.rs:53
because of an optimistic error handling (.unwrap()
) that may result in an error, for which.unwrap()
panics ifself
was anErr
.Handling the previous case, like not doing anything but at least not panicking:
moves the error (the panic) to another module, also optimistically handling errors.
The new error, if handling the previous one as above, arises in
src/input.rs:100
(.expect()
). Again an optimistic error handling, expecting that.ok_and_report()
will not result in an error, which wasn't happening because the called function was panicking instead of returning an error. Also an error occurs insrc/input.rs:88
when calling the same function as before (.ok_and_report()
) from another location in code.Couldn't reproduced it with less load (less than 20 files of less than couple of hundred of lines each), but it is consistent when having such a big amount of files opened, and LSP servers running on them.
Technical information (please complete the following information):
main
branch on GitHubThe text was updated successfully, but these errors were encountered: