OOM from textDocument/definition

[earwax1uk]

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]

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]

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]

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 🤔

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

[tgodzik]

I think this should be fixed now. We were reading too many semanticdb files at the same time, which might have caused oom with some larger files