为什么 sbt 编译失败并出现 StackOverflowError? [英] Why does sbt compile fail with StackOverflowError?
问题描述
我正在从事一个 Scala 项目，该项目已经存在了几年，但对我来说是新项目.我的任务是将它从 Scala 2.9.3 升级到 2.11.7，以及它的依赖项.我已经克服了错误和警告，但我无法在 SBT 中成功编译项目.我总是在几乎相同的地方遇到 StackOverflowError.堆栈跟踪看起来像这样，但细节因 Xss 设置而异(目前为 4M，但已尝试高达 24M):
I am working on a Scala project that has been in existence for a few years but is new to me. My task is to upgrade it from Scala 2.9.3 to 2.11.7, along with its dependencies. I have gotten past the errors and warnings, but I cannot get the project to compile successfully in SBT. I always get a StackOverflowError in pretty much the same place. The stacktrace looks like this, but details vary with the Xss setting (currently 4M, but have tried as high as 24M):
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 看起来像这样:
SBT_OPTS looks like this:
-Xmx2G -Xss4M -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled
我可以在 Intellij 中成功制作"项目，其他人可以从 GitHub 中提取我的更改并在 sbt 中编译项目，因此问题似乎出在我的机器上(最近的四核 Macbook Pro，具有 16GB RAM).其他 Scala/sbt 项目在这台机器上为我成功编译.
I can 'make' the project successfully in Intellij, and others can pull my changes from GitHub and compile the project in sbt, so the issue seems to be local to my machine (a recent quad-core Macbook Pro with 16GB RAM). Other Scala/sbt projects compile successfully for me on this machine.
以下是其他相关详细信息:
Here are other relevant 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)
我已经完全重建了ivy2缓存并清除了lib_managed目录.scala-compiler.jar 的版本与至少一台可以成功sbt 编译"代码的机器上使用的版本相同.我重新安装了 sbt(通过 brew remove sbt，手动删除 ~/.sbt 目录，然后 brew install sbt).
I have completely rebuilt the ivy2 cache and cleared the lib_managed directory. The version of the scala-compiler.jar is the same as is used on at least one machine that can 'sbt compile' the code successfully. I did a clean reinstall of sbt (via brew remove sbt, manual removal of ~/.sbt directory, then brew install sbt).
我没有尝试隔离发生错误时正在编译的源代码行.我认为在某处寻找配置问题或依赖冲突会更有效率.
I have not tried to isolate the line of source code being compiled when the error occurs. I have assumed it would be more productive to look for a configuration issue or dependency conflict somewhere.
对于进一步故障排除的任何建议将不胜感激.
Any suggestions for further troubleshooting will be appreciated.
[已添加...] 补充一点可能会有所帮助，作为实验，我从 https://github.com/scala/scala 并在尝试 sbt compile 它时遇到以下非常相似的错误:
[Added...] It may be helpful to add that, as an experiment, I downloaded the Scala language source code from https://github.com/scala/scala and got the following very similar error trying to sbt compile it:
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)
这里有一些有趣的事情.从这篇文章中，我发现了使用 -d 用于调试信息的标志.得到以下输出:
Here is something interesting. From this post I found out about launching sbt with a -d flag for debugging info. Got the following output:
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
所以我的 SBT_OPTS 设置在某处被覆盖(默认情况下，我猜).现在我需要找到这些默认值的来源.
So somewhere my SBT_OPTS settings are being overridden (by defaults, I guess). Now I need to find where those defaults are coming from.
推荐答案
我想通了.一旦我知道 -d 标志会告诉我 SBT 实际使用的设置，我看到我的 SBT_OPTS 环境变量中的值被其他较低的设置破坏了.那些是从哪里来的?来自我的 JAVA_OPTS 环境变量！我应该早点注意到它们，但现在我知道我可以保留这些 Java 选项，并通过将 SBT 特定的设置添加到我的/usr/local/etc/sbtopts 文件来覆盖them，使用
I figured it out. Once I knew that the -d flag would tell me what settings SBT was actually using, I saw that the values in my SBT_OPTS environment variable were being clobbered by other, lower settings. Where were those coming from? From my JAVA_OPTS env variable! I should have noticed them sooner, but now I know I can keep those Java options as they are and override them by adding the SBT-specific settings to my /usr/local/etc/sbtopts file, using the somewhat awkward format of
-J-Xmx2G
-J-Xss2M
使用显示的值，我能够在我的项目上成功运行 sbt compile.
Using the values shown I was able to run sbt compile successfully on my project.
我希望有人觉得这很有用.
I hope someone finds this useful.
这篇关于为什么 sbt 编译失败并出现 StackOverflowError?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
