Repository: neovim
Issue: Opening file with very long line with LSP enabled causes out-of-memory crash
Labels: bug,lsp

### Neovim version (nvim -v)

NVIM v0.8.1 Build type: Release

### Vim (not Nvim) behaves the same?

Vim doesn't have built in LSP support. With no LSP clients attached, both behave the same (vim 9.0 patches 1-813)

### Operating system/version

6.0.8-arch x86_64 GNU/Linux

### Terminal name/version

kitty 0.26.5

### $TERM environment variable

xterm-kitty

### Installation

Arch repositories

### How to reproduce the issue

The file I am getting crashes with can be obtained from `curl https://blogsurf.io/rankings/2`. It's 'only' 3.5 MB, but it's one long line.

I can get the crash to occur with the following config:
```
return require("packer").startup(function()
    use({ "neovim/nvim-lspconfig" })
    use({
        "jose-elias-alvarez/null-ls.nvim",
        config = function()
            require("plugins.null_ls")
        end,
        requires = { "nvim-lua/plenary.nvim" },
    })
end)
local null_ls = require("null-ls")
null_ls.setup({
    sources = {
        null_ls.builtins.diagnostics.todo_comments,
        null_ls.builtins.hover.printenv,
        null_ls.builtins.diagnostics.codespell
    },
})
```

I then open the file and press `$` - nvim hangs for a few seconds and then I am logged out. I get the following log output:
```
Nov 16 21:46:31 archlaptop kernel: nvim invoked oom-killer: gfp_mask=0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), order=0, oom_score_adj=0
Nov 16 21:46:31 archlaptop kernel: CPU: 8 PID: 2082 Comm: nvim Not tainted 6.0.8-arch1-1 #1 9d710c2a17e975eb42321436dd1a075089abf66c
Nov 16 21:46:31 archlaptop kernel: Call Trace:
Nov 16 21:46:31 archlaptop kernel:  <TASK>
Nov 16 21:46:31 archlaptop kernel:  dump_stack_lvl+0x48/0x60
Nov 16 21:46:31 archlaptop kernel:  dump_header+0x4a/0x1ff
Nov 16 21:46:31 archlaptop kernel:  oom_kill_process.cold+0xb/0x10
Nov 16 21:46:31 archlaptop kernel:  out_of_memory+0x27e/0x520
Nov 16 21:46:31 archlaptop kernel:  __alloc_pages_slowpath.constprop.0+0xcbe/0xe10
Nov 16 21:46:31 archlaptop kernel:  __alloc_pages+0x224/0x250
Nov 16 21:46:31 archlaptop kernel:  __folio_alloc+0x1b/0x50
Nov 16 21:46:31 archlaptop kernel:  vma_alloc_folio+0x8c/0x300
Nov 16 21:46:31 archlaptop kernel:  __handle_mm_fault+0x933/0xf70
Nov 16 21:46:31 archlaptop kernel:  handle_mm_fault+0xb2/0x290
Nov 16 21:46:31 archlaptop kernel:  do_user_addr_fault+0x1be/0x6a0
Nov 16 21:46:31 archlaptop kernel:  exc_page_fault+0x74/0x170
Nov 16 21:46:31 archlaptop kernel:  asm_exc_page_fault+0x26/0x30
Nov 16 21:46:31 archlaptop kernel: RIP: 0033:0x7ff1764a7e07
Nov 16 21:46:31 archlaptop kernel: Code: Unable to access opcode bytes at RIP 0x7ff1764a7ddd.
Nov 16 21:46:31 archlaptop kernel: RSP: 002b:00007fff6a9ec1f8 EFLAGS: 00010203
Nov 16 21:46:31 archlaptop kernel: RAX: 00007fedea827028 RBX: 00007fedea827010 RCX: 0000000000000020
Nov 16 21:46:31 archlaptop kernel: RDX: 00000000000007ac RSI: 00007fef5bd900a8 RDI: 00007fedeb4cb040
Nov 16 21:46:31 archlaptop kernel: RBP: 0000000022532d3a R08: ffffffffffffffe8 R09: 0000000000000000
Nov 16 21:46:31 archlaptop kernel: R10: 00000000000009b3 R11: 0000000000300000 R12: 00000000033707c4
Nov 16 21:46:31 archlaptop kernel: R13: 00007ff17632f380 R14: 00000000033707c4 R15: 00007ff17632f3e0
Nov 16 21:46:31 archlaptop kernel:  </TASK>
```

### Expected behavior

Don't run out of memory, since `nvim -u NONE` handles the file just fine.

### Actual behavior

The template asks me to reproduce with nvim --clean, but given the issue only turns up with a language server attached, I cannot do this. If desired, I could definitely try to reproduce without using plugins, but I think some minimal configuration is necessary, and I'm not sure what that would be for this case. Maybe test other files with similarly long lines (I think this one was over 350000 characters long) with an appropriate language server which can handle that?

Or, let me know if I should report with the null-ls plugin instead. I wasn't sure where would be best, since it's neovim itself which is able to trigger the oom killer.