scalameta / metals

Scala language server with rich IDE features 🚀
https://scalameta.org/metals/
Apache License 2.0
2.09k stars 332 forks source link

OOM from textDocument/definition #6851

Open earwax1uk opened 1 week ago

earwax1uk commented 1 week ago

Describe the bug

We're using Metals in VSCode in a code base without 5k Scala files. In the past few months we've started receiving fatal errors like the following. These occur multiple times a day per developer. We've tried increasing heap space via metals.serverProperties with no effect. We've also tried snapshot versions of Metals which haven't helped either.

What further debugging information do you need from us?

[Error - 9:17:48 AM] Request textDocument/definition failed.
  Message: Internal error.
  Code: -32603 
java.lang.OutOfMemoryError: Java heap space
    at scala.collection.immutable.VectorBuilder.<init>(Vector.scala:1403)
    at scala.meta.internal.semanticdb.Scope$.parseFrom(Scope.scala:78)
    at scala.meta.internal.semanticdb.Scope$.parseFrom(Scope.scala:74)
    at scalapb.LiteParser$.readMessage(LiteParser.scala:24)
    at scala.meta.internal.semanticdb.MethodSignature$.$anonfun$parseFrom$16(Signature.scala:553)
    at scala.meta.internal.semanticdb.MethodSignature$$$Lambda$4015/0x0000747304e1d8a0.apply(Unknown Source)
    at scala.Option.fold(Option.scala:263)
    at scala.meta.internal.semanticdb.MethodSignature$.parseFrom(Signature.scala:553)
    at scala.meta.internal.semanticdb.MethodSignature$.parseFrom(Signature.scala:541)
    at scalapb.LiteParser$.readMessage(LiteParser.scala:24)
    at scala.meta.internal.semanticdb.SignatureMessage$.$anonfun$parseFrom$3(Signature.scala:145)
    at scala.meta.internal.semanticdb.SignatureMessage$$$Lambda$4013/0x0000747304e1c420.apply(Unknown Source)
    at scala.Option.fold(Option.scala:263)
    at scala.meta.internal.semanticdb.SignatureMessage$.parseFrom(Signature.scala:145)
    at scala.meta.internal.semanticdb.SignatureMessage$.parseFrom(Signature.scala:133)
    at scalapb.LiteParser$.readMessage(LiteParser.scala:24)
    at scala.meta.internal.semanticdb.SymbolInformation$.$anonfun$parseFrom$1(SymbolInformation.scala:263)
    at scala.meta.internal.semanticdb.SymbolInformation$$$Lambda$4011/0x0000747304e1adc8.apply(Unknown Source)
    at scala.Option.fold(Option.scala:263)
    at scala.meta.internal.semanticdb.SymbolInformation$.parseFrom(SymbolInformation.scala:263)
    at scala.meta.internal.semanticdb.SymbolInformation$.parseFrom(SymbolInformation.scala:234)
    at scalapb.LiteParser$.readMessage(LiteParser.scala:24)
    at scala.meta.internal.semanticdb.TextDocument$.parseFrom(TextDocument.scala:238)
    at scala.meta.internal.semanticdb.TextDocument$.parseFrom(TextDocument.scala:210)
    at scalapb.LiteParser$.readMessage(LiteParser.scala:24)
    at scala.meta.internal.semanticdb.TextDocuments$.parseFrom(TextDocuments.scala:69)
    at scala.meta.internal.semanticdb.TextDocuments$.parseFrom(TextDocuments.scala:59)
    at scalapb.GeneratedMessageCompanion.parseFrom(GeneratedMessageCompanion.scala:175)
    at scalapb.GeneratedMessageCompanion.parseFrom$(GeneratedMessageCompanion.scala:175)
    at scala.meta.internal.semanticdb.TextDocuments$.parseFrom(TextDocuments.scala:59)
    at scala.meta.internal.mtags.Semanticdbs$.loadTextDocuments(Semanticdbs.scala:25)
    at scala.meta.internal.mtags.Semanticdbs$.loadResolvedTextDocument(Semanticdbs.scala:71)

Expected behavior

Metals not to crash with an OOM

Operating system

Linux

Editor/Extension

VS Code

Version of Metals

v1.3.5

Extra context or search terms

No response

tgodzik commented 1 week ago

Thanks for reporting! Is it always the same stack trace? I wonder if that one has actually anything to do with the memory leak or is it just coincidence. Would be useful to maybe get a heap dump, I think there is an option to have JVM dump it on OOM

earwax1uk commented 1 week ago

Yes does appear to always be the same stack trace. Will try and get a JVM dump. I believe that's -XX:+HeapDumpOnOutOfMemoryError should we add that in metals.serverProperties?

tgodzik commented 1 week ago

Yes, that's it.

If it's the same stack trace every time it seems we are generating too many semanticdb files on demand. They should only be created for build files, worksheets, scripts and standalone files :thinking:

Would you be able to also attach .metals/metals.log file?