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

E1502: Lua failed to grow stack to 4001 #1044

Open
kiryph opened this issue Jan 4, 2024 · 21 comments
Open

E1502: Lua failed to grow stack to 4001 #1044

kiryph opened this issue Jan 4, 2024 · 21 comments

Comments

@kiryph
Copy link

kiryph commented Jan 4, 2024

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

Screenshot 2024-01-04 at 09 54 21

VimR version: 0.46.0 (20240102.233758)

@georgeharker
Copy link
Collaborator

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
Copy link
Author

kiryph commented Jan 4, 2024

@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
Copy link
Collaborator

Ah that is interesting will take a look

@kiryph
Copy link
Author

kiryph commented Jan 10, 2024

@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:

Screenshot 2024-01-10 at 15 11 54

@georgeharker
Copy link
Collaborator

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
Copy link
Author

kiryph commented Jan 11, 2024

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
Copy link
Author

kiryph commented Jan 11, 2024

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.

  1. 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

Screenshot 2024-01-11 at 09 08 49

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.

@kiryph kiryph closed this as completed Jan 11, 2024
@georgeharker
Copy link
Collaborator

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

@kiryph
Copy link
Author

kiryph commented Jan 12, 2024

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.

@kiryph kiryph reopened this Jan 12, 2024
@p3palazzo
Copy link

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
Copy link
Collaborator

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
Copy link

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

@mmerickel
Copy link

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
Copy link

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
Copy link

MikaAK commented Mar 18, 2024

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
Copy link
Contributor

nclark commented Apr 9, 2024

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
Copy link

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
Copy link
Contributor

nclark commented Apr 9, 2024

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
Copy link
Contributor

nclark commented Apr 11, 2024

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
Copy link

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants