Warum schlägt die sbt-Kompilierung mit StackOverflowError fehl?

Question

Ich arbeite an einem Scala-Projekt, das seit einigen Jahren existiert, aber für mich neu ist. Meine Aufgabe besteht darin, sie von Scala 2.9.3 auf 2.11.7 mit ihren Abhängigkeiten aufzurüsten. Ich habe die Fehler und Warnungen überstanden, aber ich kann das Projekt nicht erfolgreich in SBT kompilieren. Ich bekomme immer einen StackOverflowError an fast genau der gleichen Stelle. Die Stacktrace sieht wie folgt aus, aber Details variieren mit der Xss Einstellung (derzeit 4M, haben aber so hoch wie 24M versucht):

java.lang.StackOverflowError 
at scala.tools.nsc.transform.Erasure$Eraser.typed1(Erasure.scala:698) 
at scala.tools.nsc.typechecker.Typers$Typer.runTyper$1(Typers.scala:5395) 
at scala.tools.nsc.typechecker.Typers$Typer.scala$tools$nsc$typechecker$Typers$Typer$$typedInternal(Typers.scala:5422) 
at scala.tools.nsc.typechecker.Typers$Typer.body$2(Typers.scala:5369) 
at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:5373) 
at scala.tools.nsc.typechecker.Typers$Typer.typedQualifier(Typers.scala:5471) 
at scala.tools.nsc.typechecker.Typers$Typer.typedQualifier(Typers.scala:5479) 
at scala.tools.nsc.transform.Erasure$Eraser.adaptMember(Erasure.scala:644) 
at scala.tools.nsc.transform.Erasure$Eraser.typed1(Erasure.scala:698) 
at scala.tools.nsc.typechecker.Typers$Typer.runTyper$1(Typers.scala:5395) 
at scala.tools.nsc.typechecker.Typers$Typer.scala$tools$nsc$typechecker$Typers$Typer$$typedInternal(Typers.scala:5422) 

SBT_OPTS wie folgt aussieht:

-Xmx2G -Xss4M -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled 

Ich kann 'make' das Projekt erfolgreich in Intellij, und andere können meine Änderungen von GitHub ziehen und das Projekt in sbt kompilieren, so scheint das Problem lokal auf meinem Computer zu sein (ein kürzlich Quad-Core-Macbook Pro mit 16 GB RAM). Andere Scala/sbt-Projekte werden für mich auf diesem Rechner erfolgreich kompiliert.

Hier sind andere relevante Details:

Scala version: 2.11.7 
Java version: java version "1.8.0_66" (build 1.8.0_66-b17) 
sbt version: 0.13.7 (have also tried 0.13.9) 

ich vollständig den ivy2 Cache wieder aufgebaut und gelöscht das lib_managed Verzeichnis. Die Version der scala-compiler.jar ist dieselbe wie sie auf mindestens einer Maschine verwendet wird, die den Code erfolgreich kompilieren kann. Ich habe eine saubere Neuinstallation von sbt (über brew remove sbt, manuelle Entfernung von ~/.SBT-Verzeichnis, dann brew install sbt).

Ich habe nicht versucht, die Zeile des Quellcodes, der kompiliert wird, wenn der Fehler auftritt, zu isolieren. Ich habe angenommen, dass es produktiver wäre, irgendwo nach einem Konfigurationsproblem oder einem Abhängigkeitskonflikt zu suchen.

Alle Vorschläge zur weiteren Fehlerbehebung werden geschätzt.

[Added ...] Es kann hilfreich sein, hinzuzufügen, dass, als ein Experiment, die ich heruntergeladen hat, die Quelle Scala Sprachcode von https://github.com/scala/scala und bekam die folgenden sehr ähnlichen Fehler zu sbt compile versuchen es:

java.lang.StackOverflowError 
at scala.tools.nsc.transform.ExplicitOuter$OuterPathTransformer.outerValue(ExplicitOuter.scala:229) 
at scala.tools.nsc.transform.ExplicitOuter$ExplicitOuterTransformer.transform(ExplicitOuter.scala:441) 
at scala.tools.nsc.transform.ExplicitOuter$ExplicitOuterTransformer.transform(ExplicitOuter.scala:352) 
at scala.reflect.internal.Trees$class.itransform(Trees.scala:1345) 
at scala.reflect.internal.SymbolTable.itransform(SymbolTable.scala:16) 
at scala.reflect.internal.SymbolTable.itransform(SymbolTable.scala:16) 
at scala.reflect.api.Trees$Transformer.transform(Trees.scala:2555) 
at scala.tools.nsc.transform.TypingTransformers$TypingTransformer.transform(TypingTransformers.scala:44) 
at scala.tools.nsc.transform.ExplicitOuter$OuterPathTransformer.scala$reflect$internal$Trees$UnderConstructionTransformer$$super$transform(ExplicitOuter.scala:219) 
at scala.reflect.internal.Trees$UnderConstructionTransformer$class.transform(Trees.scala:1693) 
at scala.tools.nsc.transform.ExplicitOuter$OuterPathTransformer.transform(ExplicitOuter.scala:291) 
at scala.tools.nsc.transform.ExplicitOuter$ExplicitOuterTransformer.transform(ExplicitOuter.scala:459) 
at scala.tools.nsc.transform.ExplicitOuter$ExplicitOuterTransformer.transform(ExplicitOuter.scala:352) 
at scala.reflect.internal.Trees$class.itransform(Trees.scala:1347) 
at scala.reflect.internal.SymbolTable.itransform(SymbolTable.scala:16) 
at scala.reflect.internal.SymbolTable.itransform(SymbolTable.scala:16) 
at scala.reflect.api.Trees$Transformer.transform(Trees.scala:2555) 

Hier ist etwas Interessantes. Von this post10 habe ich über das Starten von sbt mit einem -d-Flag für Debugging-Informationen erfahren. Haben Sie die folgende Ausgabe:

Kevins-MacBook-Pro:scala kdoherty$ sbt -d 
[process_args] java_version = '1.8.0_66' 
# Executing command line: 
java 
-Xmx2G 
-Xss4M 
-XX:+UseConcMarkSweepGC 
-XX:+CMSClassUnloadingEnabled 
-Xmx384m 
-Xss512k 
-XX:+UseCompressedOops 
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 
-jar 
/usr/local/Cellar/sbt/0.13.9/libexec/sbt-launch.jar 

Also irgendwo meine SBT_OPTS Einstellungen außer Kraft gesetzt werden (durch Standardwerte, glaube ich). Jetzt muss ich herausfinden, woher diese Vorgaben kommen.

Answer 1

Ich fand es heraus. Sobald ich wusste, dass das Flag -d mir sagen würde, welche Einstellungen SBT tatsächlich verwendete, sah ich, dass die Werte in meiner Umgebungsvariablen SBT_OPTS durch andere, niedrigere Einstellungen verunstaltet wurden. Woher kamen die? Von meiner Variablen JAVA_OPTS env! Ich hätte sie früher bemerken sollen, aber jetzt weiß ich, dass ich diese Java-Optionen beibehalten kann und die ihnen überschreibe, indem ich die SBT-spezifischen Einstellungen zu meiner/usr/local/etc/sbtopts-Datei hinzufüge und das etwas peinliche Format von

-J-Xmx2G 
-J-Xss2M 

Unter Verwendung der Werte gezeigt ich in der Lage war sbt compile erfolgreich auf meinem Projekt auszuführen.

Ich hoffe jemand findet das nützlich.