E1502: Lua failed to grow stack to 4001

[kiryph]

When I open a larger tex file in VimR (version 4.46.0), I get following error:

E1502: Lua failed to grow stack to 4001
E1502: Lua failed to grow stack to 4001
...

I do not get the error in VimR version 0.44.0 with neovim 0.8.2 from January 2023.

I use the ftplugin VimTeX.

I raise this issue in the repository of VimR since I do not get the error on the command line or with other neovim guis such as neovim-qt or neovide.

Steps to reproduce:

1. Install VimTeX, e.g. with lazy.nvim (My config started from kickstart-modular.nvim)
2. Open following tex file from the test folder of VimTeX:

~/.local/share/nvim/lazy/vimtex/test/test-toc-speed/main.tex

VimR version: 0.46.0 (20240102.233758)

[georgeharker]

It’s probably a neovim issue but you can point your vimr at the command line version you’re using in advanced prefs to check if that’s the case.

[kiryph]

@georgeharker Thanks for chiming in.

However, I have installed the same neovim version on cli 0.9.5 where I cannot reproduce the issue

❯ nvim --version
NVIM v0.9.5
Build type: Release
LuaJIT 2.1.1692716794

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/local/share/nvim"

Run :checkhealth for more info
(base)

Opening the tex file is fine:

❯ nvim  ~/.local/share/nvim/lazy/vimtex/test/test-toc-speed/main.tex

Also pointing to the nvim binary installed from https://github.com/neovim/neovim/releases/tag/v0.9.5 for macOS does not remove the issue.

[georgeharker]

Ah that is interesting will take a look

[kiryph]

@georgeharker Thanks for taking a look. Could you at least reproduce it?

When I install VimR version v0.44.0 with neovim 0.8.2 from January 2023, I do not get the error:

[georgeharker]

I don't use Lazy.nvim but installed via packer and see the same thing.

I also see the same with an external nvim but have zero idea why. Tried TSUpdate, Packerupdate to see if something was out of sync. I don't have an earlier neovim to hand to test if it's a neovim issue - but strongly suspect it's that or an incompatibility with vimtex and neovim version.

I also saw errors saying tree sitter was doing the highlighting - perhaps worth asking over at vimtex, or seeing if you can try a local neovim at an earlier version to validate if if's neovim at issue (we just invoke a neovim binary that we bundle, so I'm doubtful anything in the vimR code base would be causing this, it's probably just something in neovim / vimtex compatibility which I don't understand).

[kiryph]

I don't use Lazy.nvim but installed via packer and see the same thing.

I do not think this issue is related to the used package manager (packer or lazy).

I also see the same with an external nvim but have zero idea why.

Thanks for the confirmation.

Tried TSUpdate, Packerupdate to see if something was out of sync.

I do not think that an outdated package or tree-sitter grammar is the reason.

but strongly suspect it's that or an incompatibility with vimtex and neovim version.

This is what I cannot confirm. I am using vimtex for several years and neovim for about 2 years as my daily editor.

~~This issue only occurs in the new VimR release with any neovim version. I have tried so far neovim versions 0.9.5, 0.9.0, 0.8.3, 0.8.2~~ (Update: versions 0.8.x are not compatible with VimR 0.46.0):

I don't have an earlier neovim to hand to test if it's a neovim issue

One can install diferrent neovim versions with bob.

perhaps worth asking over at vimtex,

Maybe I do this. The author of vimtex is always very helpful even though he is on Linux and not macOS.

I also saw errors saying tree sitter was doing the highlighting

VimTeX defines classic syntax highlighting groups and is vital for some of its functionality and recommends to disable treesitter for tex files.

Thus, for people who use Tree-sitter, it is strongly advised to disable Tree-sitter highlighting for LaTeX buffers. This can be done with the ignore_install option for the setup part of nvim-treesitter, e.g.: >lua

Full FAQ entry can be found here.

Hence my tree sitter config is:

vim.defer_fn(function()
  require('nvim-treesitter.configs').setup {
    -- Add languages to be installed here that you want installed for treesitter
    ensure_installed = { 'c', 'cpp', 'go', 'lua', 'python', 'rust', 'tsx',
      'javascript', 'typescript', 'vimdoc', 'vim', 'bash' },

    -- Autoinstall languages that are not installed. Defaults to false (but you can change for yourself!)
    auto_install = false,

    highlight = {
      enable = true,
      disable = { "tex" },
    },
...

or seeing if you can try a local neovim at an earlier version to validate if if's neovim at issue (we just invoke a neovim binary that we bundle, so I'm doubtful anything in the vimR code base would be causing this, it's probably just something in neovim / vimtex compatibility which I don't understand).

I guess I have to debug it better to see from where these errors come.

[kiryph]

Sorry for the noise and confusion in this issue.

1. Version 0.8.x are not compatible with the new VimR release. So I could not test them at all.

I did not first notice that in VimR configuration dialog tilde expansion for home directory does not work.

Maybe an error could be thrown if the entered path to a binary points to a non-existing file.

2. ~I could resolve the issue by correctly pointing to a manual installation of neovim 0.9.5~

/Users/kiryph/.local/share/bob/v0.9.5/nvim-macos/bin/nvim

Following is outdated, since the issue remains:

~So the issue might be related to the nvim binary included in VimR.~

~Nevertheless I close this issue since I have a solution for me.~

[georgeharker]

Ok great. I’m so glad there’s a workaround. We can grab a new neovim version when we next release.

[kiryph]

I tried it on a fresh new day and unfortunately, the issue persists. I am not sure what was different to the last time I tried it.

I guess it has to be figured out what the error actually throws.

[p3palazzo]

I get this warning every time I navigate to a memory-intensive buffer such as a large file or the NERDTree split, both when using the builtin neovim and the Homebrew neovim binary.

[georgeharker]

It was my understanding that our build is now vanilla neovim but perhaps we should explicitly set a larger stack size if it is not.

[chrisfosterelli]

Stumbled across here from Google. I also seem to get this error a ton if NERDTree is open. I don't use VimTeX.

[mmerickel]

I'm running into this regularly. I do use NERDTree and always have it open. I tried using the CLI version of VIM instead of the version shipped with vimR but same issue regardless (albeit seems to take more minutes before it shows up whereas it's usually within a minute with the builtin nvim).

Using system NVIM (/opt/homebrew/bin/nvim):

NVIM v0.9.5
Build type: Release
LuaJIT 2.1.1703358377

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/opt/homebrew/Cellar/neovim/0.9.5/share/nvim"

Using builtin NVIM:

NVIM v0.9.5
Build type: Release
LuaJIT 2.1.1692716794

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/local/share/nvim"

[mmerickel]

To be clear above, I have not seen this issue when running neovim directly in a terminal console - only when running through vimR with various neovim binaries selected.

[MikaAK]

I'm also getting this regularly, it's getting quite frustrating as I have to restart my editor randomly or this makes me basically unable to work. Any ideas on how we can set the stack size higher? To confirm what @mmerickel is saying I do not get this is normal neovim only vimr

Furthermore this seems to cause a hang when quitting if you ignore it too long

Mac Debug Report

Date/Time: 2024-03-18 14:21:27.734 -0700 End time: 2024-03-18 14:21:39.169 -0700 OS Version: macOS 12.5.1 (Build 21G83) Architecture: arm64e Report Version: 35.1 Incident Identifier: BF81EA4F-317E-4DA3-9FE8-63A102103783

Data Source: Stackshots Shared Cache: F8AB76FB-504C-32DD-A5DB-15A1F2F028F8 slid base address 0x191200000, slide 0x11200000 Shared Cache: AE0CAA53-3B48-3816-ABB7-3258C48580E1 slid base address 0x1a2928000, slide 0x22928000 Shared Cache: F3387257-F96F-3907-B94C-1D7F0EBEF98B slid base address 0x7ff81aec8000, slide 0x1aec8000

Command: VimR Path: /Applications/VimR.app/Contents/MacOS/VimR Identifier: com.qvacua.VimR Version: 0.46.1 (20240114.181346) Team ID: H96Q2NKTQH Architecture: arm64 Parent: launchd [1] PID: 562 Time Since Fork: 435804s

Event: hang Duration: 11.44s Duration Sampled: 4.50s (process was unresponsive for 7 seconds before sampling) Steps: 45 (100ms sampling interval)

Hardware model: MacBookPro18,4 Active cpus: 10 HW page size: 16384 VM page size: 16384

Time Awake Since Boot: 170563s Time Since Wake: 3400s

Fan speed: 0 rpm Total CPU Time: 10.730s (25.4G cycles, 81.8G instructions, 0.31c/i) Advisory levels: Battery -> 1, User -> 2, ThermalPressure -> 0, Combined -> 1 Free disk space: 1192.44 GB/1858.19 GB, low space threshold 3072 MB

---

Timeline format: stacks are sorted chronologically Use -i and -heavy to re-report with count sorting

Heaviest stack for the main thread of the target process: 45 start + 520 (dyld + 20620) [0x100af108c] 45 main + 36 (VimR + 31304) [0x100483a48] 45 NSApplicationMain + 1132 (AppKit + 14076) [0x1941206fc] 45 -[NSApplication run] + 636 (AppKit + 204808) [0x19414f008] 45 -[NSApplication _handleEvent:] + 76 (AppKit + 4628724) [0x1945870f4] 45 -[NSApplication(NSEvent) sendEvent:] + 1172 (AppKit + 1769068) [0x1942cce6c] 45 routeKeyEquivalent + 568 (AppKit + 8065532) [0x1948ce1fc] 45 -[NSMenu performKeyEquivalent:] + 452 (AppKit + 3384068) [0x194457304] 45 -[NSMenu _performActionForItem:atIndex:fromEvent:] + 228 (AppKit + 6774988) [0x1947930cc] 45 -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 100 (AppKit + 3387360) [0x194457fe0] 45 -[NSMenuItem _corePerformAction] + 444 (AppKit + 3388140) [0x1944582ec] 45 -[NSApplication(NSResponder) sendAction:to:from:] + 460 (AppKit + 2381256) [0x1943625c8] 45 -[NSApplication terminate:] + 740 (AppKit + 2911352) [0x1943e3c78] 45 -[NSApplication _shouldTerminate] + 768 (AppKit + 2975036) [0x1943f353c] 45 -[NSDocumentController(NSInternal) __closeAllDocumentsWithDelegate:shouldTerminateSelector:] + 256 (AppKit + 2975972) [0x1943f38e4] 45 -[NSDocumentController(NSInternal) _closeAllDocumentsWithDelegate:shouldTerminateSelector:] + 1088 (AppKit + 2977120) [0x1943f3d60] 45 __91-[NSDocumentController(NSInternal) _closeAllDocumentsWithDelegate:shouldTerminateSelector:]_block_invoke + 392 (AppKit + 2978012) [0x1943f40dc] 45 -[NSApplication _docController:shouldTerminate:] + 88 (AppKit + 2978388) [0x1943f4254] 45 ??? (VimR + 26372) [0x100482704] 45 ??? (VimR + 39436) [0x100485a0c] 29 ??? (VimR + 240128) [0x1004b6a00] 29 ??? (VimR + 3278780) [0x10079c7bc] 29 -[NSCondition waitUntilDate:] + 148 (Foundation + 245240) [0x1924b3df8] 29 __psynch_cvwait + 8 (libsystem_kernel.dylib + 21104) [0x1914f2270] *29 psynch_cvcontinue + 0 (pthread + 17956) [0xfffffe000a59be54]

Process: VimR [562] UUID: 8F52E760-AF7D-34F6-BAE2-5722DAFD0EE6 Path: /Applications/VimR.app/Contents/MacOS/VimR Identifier: com.qvacua.VimR Version: 0.46.1 (20240114.181346) Team ID: H96Q2NKTQH Shared Cache: F8AB76FB-504C-32DD-A5DB-15A1F2F028F8 slid base address 0x191200000, slide 0x11200000 Architecture: arm64 Parent: launchd [1] UID: 501 Footprint: 135.32 MB Time Since Fork: 435804s Num samples: 45 (1-45) CPU Time: 0.012s (36.2M cycles, 33.4M instructions, 1.08c/i) Note: Unresponsive for 7 seconds before sampling Note: 3 idle work queue threads omitted

Thread 0x147d DispatchQueue "com.apple.main-thread"(1) 45 samples (1-45) priority 47 (base 47) cpu time <0.001s (94.5K cycles, 41.9K instructions, 2.26c/i) <process frontmost, thread QoS user interactive (requested user interactive), process unclamped, process received importance donation from WindowServer [180], IO tier 0> 45 start + 520 (dyld + 20620) [0x100af108c] 1-45 45 main + 36 (VimR + 31304) [0x100483a48] 1-45 45 NSApplicationMain + 1132 (AppKit + 14076) [0x1941206fc] 1-45 45 -[NSApplication run] + 636 (AppKit + 204808) [0x19414f008] 1-45 45 -[NSApplication _handleEvent:] + 76 (AppKit + 4628724) [0x1945870f4] 1-45 45 -[NSApplication(NSEvent) sendEvent:] + 1172 (AppKit + 1769068) [0x1942cce6c] 1-45 45 routeKeyEquivalent + 568 (AppKit + 8065532) [0x1948ce1fc] 1-45 45 -[NSMenu performKeyEquivalent:] + 452 (AppKit + 3384068) [0x194457304] 1-45 45 -[NSMenu _performActionForItem:atIndex:fromEvent:] + 228 (AppKit + 6774988) [0x1947930cc] 1-45 45 -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 100 (AppKit + 3387360) [0x194457fe0] 1-45 45 -[NSMenuItem _corePerformAction] + 444 (AppKit + 3388140) [0x1944582ec] 1-45 45 -[NSApplication(NSResponder) sendAction:to:from:] + 460 (AppKit + 2381256) [0x1943625c8] 1-45 45 -[NSApplication terminate:] + 740 (AppKit + 2911352) [0x1943e3c78] 1-45 45 -[NSApplication _shouldTerminate] + 768 (AppKit + 2975036) [0x1943f353c] 1-45 45 -[NSDocumentController(NSInternal) __closeAllDocumentsWithDelegate:shouldTerminateSelector:] + 256 (AppKit + 2975972) [0x1943f38e4] 1-45 45 -[NSDocumentController(NSInternal) _closeAllDocumentsWithDelegate:shouldTerminateSelector:] + 1088 (AppKit + 2977120) [0x1943f3d60] 1-45 45 __91-[NSDocumentController(NSInternal) _closeAllDocumentsWithDelegate:shouldTerminateSelector:]_block_invoke + 392 (AppKit + 2978012) [0x1943f40dc] 1-45 45 -[NSApplication _docController:shouldTerminate:] + 88 (AppKit + 2978388) [0x1943f4254] 1-45 45 ??? (VimR + 26372) [0x100482704] 1-45 45 ??? (VimR + 39436) [0x100485a0c] 1-45 29 ??? (VimR + 240128) [0x1004b6a00] 1-29 29 ??? (VimR + 3278780) [0x10079c7bc] 1-29 29 -[NSCondition waitUntilDate:] + 148 (Foundation + 245240) [0x1924b3df8] 1-29 29 __psynch_cvwait + 8 (libsystem_kernel.dylib + 21104) [0x1914f2270] 1-29 *29 psynch_cvcontinue + 0 (pthread + 17956) [0xfffffe000a59be54] 1-29 16 ??? (VimR + 240280) [0x1004b6a98] 30-45 16 ??? (VimR + 3040640) [0x100762580] 30-45 16 ??? (VimR + 2415428) [0x1006c9b44] 30-45 16 -[NSCondition waitUntilDate:] + 148 (Foundation + 245240) [0x1924b3df8] 30-45 16 __psynch_cvwait + 8 (libsystem_kernel.dylib + 21104) [0x1914f2270] 30-45 *16 psynch_cvcontinue + 0 (pthread + 17956) [0xfffffe000a59be54] 30-45

[nclark]

Has anyone found a combination of older versions of nvim or vimr that stops this? I can't take it anymore. I'd love to keep using vimr but I am going to switch editors soon.

[mmerickel]

Anecdotally the error has disappeared for me since I switched to nvim-tree so in my little world of plugins nerdtree feels like it was the primary culprit. Would love to see whatever setting vimr is using be configurable or higher or whatever is required to avoid it occurring though since obviously it never occurred for me via the cli.

[nclark]

I went to the releases page, scrolled down a bit, landed on VimR-v0.43.0.tar.bz2 for no reason in particular, and switched to that. Things seem to be working for me now (fingers crossed), nerdtree and all. I'll try @mmerickel's approach at some point.

[nclark]

I went to the releases page, scrolled down a bit, landed on VimR-v0.43.0.tar.bz2 for no reason in particular, and switched to that. Things seem to be working for me now (fingers crossed), nerdtree and all. I'll try @mmerickel's approach at some point.

Never mind, that stopped it for like one day.

[nashalex]

i've found that downgrading to version 0.44.0 stops this problem. although, it seems that sometimes the VimR.app file automatically updates itself after the app is closed and reopened. but reinstalling version 0.44.0 before opening the app seems to "stop" this problem. (although it does get a bit tedious.)

at this point i just have an unzipped version of v0.44.0 that i drag into my applications directory before i open the app.

[lukeasrodgers]

As others have mentioned in this thread, the problem goes away when I either

• downgrade to v0.44.0; or
• switch NERDtree to nvim-tree