Possible stack overflow

[sigmundch]

I've run into some stack overflow errors at times, not sure yet on the possible cause.

I can repro easily in the dart sdk repo, standing on the root, and opening some files under the tests folder.

For example, if I open tests/language/issue4295001_test.dart, I then see this error:

Error detected while processing function lsc#server#channelCallback[3]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMe
ssage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#cons
umeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol
#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#pro
tocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..ls
c#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24
]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessa
ge[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consume
Message[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#co
nsumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protoc
ol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#p
rotocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..
lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[
24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMes
sage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consu
meMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#
consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#prot
ocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc#protocol#consumeMessage[24]..lsc
#protocol#co

Followed by this error:

E132: Function call depth is higher than 'maxfuncdepth'

[natebosch]

Would be good to see what message the server sent which led to this.

Messages can get split up into chunks and this function recurses until it's consumed every chunk in a message. maxfuncdepth has a default of 100 and if a huge message, say a message with many diagnostics, get's split into >100 chunks this could happen.

Hopefully that is what is happening here - do you know if this file is likely to have a lot of diagnostics?

I will refactor to get rid of the recursion and see if that resolves it. If not there might be some other bug where we misread the message length or something like that.

[natebosch]

As a temporary workaround you could try set maxfuncdepth=200 and see if it buys enough headroom - that would also let us know if there is a broken end condition or if refactoring away from recursion is all we need.

[sigmundch]

if you run dartanalyzer on the file, you only see 2 warnings, however, when I tee the output from the server, I see about 4000 publishDiagnostics messages.

I think the issue might be that this folder has 2K source files (all independent of each other). So quite likely the issue is that analyzer is processing all the files in the folder. :(

I was curious about whether we avoided this issue in the ycm pluggin, but no, we also set the directory as an analysis root like you do in lsc. While looking there I noticed that we did set the opened source file as a priority-file in ycmd, are you also doing that also in lsc?

[natebosch]

LSP doesn't have a notion of priority files so we don't do that in this client - but in the dart_language_server we always set open files as priority files

There are probably some optimizations we could make in dart_language_server that could help here. I wonder if we should swallow diagnostics for files that aren't open. At least this client doesn't care about them but maybe other clients do? Filed natebosch/dart_lsp#15 to track.

In any case we probably don't want to set maxfuncdepth that high so I'll try to get in the refactoring to change to a loop ASAP.

[natebosch]

Update to the latest and this should be resolved. I couldn't quite hit the problem with the default maxfuncdepth but by setting it artificially low I could repro. Switched to a loop and we shouldn't see this problem again.