Skip to content
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

Closed
baco opened this issue May 30, 2024 · 3 comments · Fixed by #115
Closed

Random crash on sudden navigation #112

baco opened this issue May 30, 2024 · 3 comments · Fixed by #115
Assignees
Labels
bug Something isn't working

Comments

@baco
Copy link

baco commented May 30, 2024

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 if self was an Err.

Handling the previous case, like not doing anything but at least not panicking:

    fn ok_and_report(self) -> Option<T> {
        self.report_err();
        match self {
            Ok(msg) => Some(msg),
            Err(_) => None,
        }
    }

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 in src/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):

  • OS: GNU/Linux Debian testing
  • Neovim version: v0.10.0
  • Neovim-Gtk build version: main branch on GitHub
@Lyude Lyude added the bug Something isn't working label Jun 6, 2024
@Lyude
Copy link
Owner

Lyude commented Jun 6, 2024

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

@Lyude Lyude self-assigned this Jun 17, 2024
@Lyude
Copy link
Owner

Lyude commented Jun 17, 2024

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?).
If you drop the .expect() in src/input.rs does the session still work properly afterwards?

@Lyude
Copy link
Owner

Lyude commented Jun 30, 2024

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)

Lyude added a commit that referenced this issue Jul 11, 2024
Lyude added a commit that referenced this issue Jul 11, 2024
@Lyude Lyude closed this as completed in dfe6d12 Jul 11, 2024
Lyude added a commit that referenced this issue Oct 4, 2024
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.
Lyude added a commit that referenced this issue Oct 4, 2024
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.
Lyude added a commit that referenced this issue Oct 4, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants