Crash — thread '<unknown>' has overflowed its stack

[Erik Kerber]

When running in my main project, starpls terminates immediately. This is in the LSP logs:

(via NeoVim LSP, but that probably isn't material)

[ERROR][2024-04-19 09:20:48] .../vim/lsp/rpc.lua:734	"rpc"	"/opt/homebrew/bin/starpls"	"stderr"	"\nthread '<unknown>' has overflowed its stack\nfatal runtime error: stack overflow\n"

The event prior was a basic textDocument/didChange

[withered-magic]

Thanks for reporting! A couple questions:

• Does this happen for only the main project in question, or does it happen for any Bazel source file in even a simple project? If it's the latter I can try reproing on Neovim (I primarily use VSCode so not sure if there's some editor-specific thing I haven't taken into account)
• If it's the former and specific to the main project, are you able to narrow down what file is causing the crash? starpls doesn't yet walk the project directory to pre-index files and only processes files as you open them in the editor (or when they're loaded by other files), so you might be able to narrow down which file is causing the crash by opening files one at a time. Maybe Neovim shows which files are getting opened if it logs the textDocument/didOpen notifications?

My hunch is that it's some edge case in the parser (since that's the only place that really uses recursion at all and would result in a stack overflow), but if you can provide a quick repro I can definitely look into this!

[Erik Kerber]

I just toyed around and it seems certain files/buffers do it for me. So it actually worked for a bit in my main repo until I switched to one of our more complex macro files and it crashed right away.

So yeah I can probably repro it with some known files, but aren't quite sure the best way I can debug it. Could be a matter of getting this building myself.

[withered-magic]

Ah interesting - unfortunately I don't really have much good debugging instructions rn but one quick thing we could probably try to narrow it down is to see if you can identify the particular syntax that's causing the crash by continuously removing things from a file till it doesn't crash, and then adding them back until it does. And then from there it should be easier to come up with a generic repro I think!

At a high level though, the pipeline that the files kind of go through is as follows:

• parsing
• lowering
• calculating scopes
• and type checking

So if you get it building, then these would probably be the four sort of areas I'd jump to first!

Maybe a couple follow up questions: how complex are the files in question, and maybe is there anything unusual in common between their contents? For reference, I've mostly been testing against our main repo at work, the Bazel and BuildBuddy repos, and some open source rulesets which has helped to iron out a lot of edge cases but I'm sure there are still a bunch left to catch!

[withered-magic]

@erikkerber Was wondering if you were still running into this?

[Erik Kerber]

I just pulled down v14 and it looks like it's fixed!

[withered-magic]

awesome glad to hear! i'll close this issue for now but if you run into this again please feel free to open a new one!