Scala maven plugin doesn't compile with StackOverflowError

Question

I found a bug related to Scala-maven-plugin in my Maven project. I have a very long Sequence of features (for Machine Learning purposes) I hand-coded (74 elements).

I added one element in the sequence and it doesn't compile anymore. If I comment any element of this sequence, the number of elements decreases and it compiles.

For more information, here is the final output of my compilation:

[ERROR] Failed to execute goal net.alchim31.maven:scala-maven-plugin:3.3.1:compile (default) on project SecretProject: wrap: org.apache.commons.exec.ExecuteException: Process exited with an error: 240 (Exit value: 240) -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

Plus the very beginning of the StackTrace:

[INFO] Compiling 13 source files to /home/belka/Bureau/SecretProject/target/classes at 1513759339071
[ERROR] error: java.lang.StackOverflowError
[INFO]  at scala.reflect.internal.TreeInfo.isSelfConstrCall(TreeInfo.scala:296)
[INFO]  at scala.reflect.internal.TreeInfo.isSelfOrSuperConstrCall(TreeInfo.scala:344)
[INFO]  at scala.reflect.internal.Trees$UnderConstructionTransformer$class.transform(Trees.scala:1701)
[INFO]  at scala.tools.nsc.transform.ExplicitOuter$OuterPathTransformer.transform(ExplicitOuter.scala:291)
[INFO]  at scala.tools.nsc.transform.ExplicitOuter$ExplicitOuterTransformer.transform(ExplicitOuter.scala:457)
[INFO]  at scala.tools.nsc.transform.ExplicitOuter$ExplicitOuterTransformer.transform(ExplicitOuter.scala:352)
[INFO]  at scala.reflect.internal.Trees$class.itransform(Trees.scala:1345)

(modified project name)

• Did anyone encounter a similar issue with Scala-maven-plugin?
• Does Scala-maven-plugin parser (in the compiler) have any sort of hard limit for Sequences parsing?
• How to solve it and compile my project?
• Why does it work with IntelliJ compilation ("play" button) but not with Maven compilation?

EDIT:

I'm adding the pom.xml fragment containing my Scala-maven-plugin fragment:

      <plugin>
        <!-- see http://davidb.github.com/scala-maven-plugin -->
        <groupId>net.alchim31.maven</groupId>
        <artifactId>scala-maven-plugin</artifactId>
        <version>3.3.1</version>
        <executions>
          <execution>
            <goals>
              <goal>compile</goal>
              <goal>testCompile</goal>
            </goals>
            <configuration>
              <args>
                <arg>-dependencyfile</arg>
                <arg>${project.build.directory}/.scala_dependencies</arg>
              </args>
              <jvmArgs>
                <jvmArg>-Xms512m</jvmArg>
                <jvmArg>-Xmx4096m</jvmArg>
              </jvmArgs>
            </configuration>
          </execution>
        </executions>
      </plugin>

Answer 1

You could :

• de-recursive your code or use tail recursive

• or increase the max stack size of the jvm used to run scalac via -Xss

        <jvmArgs>
          <jvmArg>-Xss4m</jvmArg>
          <jvmArg>-Xms512m</jvmArg>
          <jvmArg>-Xmx4096m</jvmArg>
        </jvmArgs>
  

I guess IDEA already increase the default max stack size (iirc 1024k in the 64-bit VM).

Answer 2

To answer you questions by order:

• Yes. See this for the problem and solution.
• JVM has a stack limit, now I am speculating a bit but when parsing code usually a stack is used and if it is recursive (oi vey) it makes sense that having a very long sequence to parse will take more stack memory. Apperantly under the memory usage of maven and the scala parser it is too much.
• To solve it see link above.
• Might be like I mentioned above that maven has more stack memory consumption than intellij. Edit: I think it more likely depends on how the compiler process is started, if I am not mistaken it might have different stack state.