luna: Stackoverflow

I tried running the server and got this

08 Feb 2017 23:58:27 io.luna.game.plugin.PluginBootstrap [LunaInitializationThread] ERROR: Catching java.lang.StackOverflowError: null at scala.tools.nsc.typechecker.Contexts$Context.bufferErrors(Contexts.scala:332) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Contexts$Context.reportErrors(Contexts.scala:333) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Typers$Typer.silent(Typers.scala:672) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Typers$Typer.normalTypedApply$1(Typers.scala:4524) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Typers$Typer.typedApply$1(Typers.scala:4580) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Typers$Typer.typedInAnyMode$1(Typers.scala:5343) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Typers$Typer.typed1(Typers.scala:5360) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.transform.Erasure$Eraser.typed1(Erasure.scala:698) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Typers$Typer.runTyper$1(Typers.scala:5396) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Typers$Typer.scala$tools$nsc$typechecker$Typers$Typer$$typedInternal(Typers.scala:5423) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Typers$Typer.body$2(Typers.scala:5370) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:5374) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Typers$Typer.typedQualifier(Typers.scala:5472) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Typers$Typer.typedQualifier(Typers.scala:5480) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.transform.Erasure$Eraser.adaptMember(Erasure.scala:644) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.transform.Erasure$Eraser.typed1(Erasure.scala:698) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Typers$Typer.runTyper$1(Typers.scala:5396) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Typers$Typer.scala$tools$nsc$typechecker$Typers$Typer$$typedInternal(Typers.scala:5423) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Typers$Typer.body$2(Typers.scala:5370) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:5374) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Typers$Typer$$anonfun$99.apply(Typers.scala:4525) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Typers$Typer$$anonfun$99.apply(Typers.scala:4525) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Typers$Typer.silent(Typers.scala:680) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Typers$Typer.normalTypedApply$1(Typers.scala:4524) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Typers$Typer.typedApply$1(Typers.scala:4580) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Typers$Typer.typedInAnyMode$1(Typers.scala:5343) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Typers$Typer.typed1(Typers.scala:5360) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.transform.Erasure$Eraser.typed1(Erasure.scala:698) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Typers$Typer.runTyper$1(Typers.scala:5396) ~[scala-compiler-2.11.8.jar:?] at scala.tools.nsc.typechecker.Typers$Typer.scala$tools$nsc$typechecker$Typers$Typer$$typedInternal(Typers.scala:5423) ~[scala-compiler-2.11.8.jar:?]

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 19 (12 by maintainers)

Most upvoted comments

It is very, VERY unusual for an application this small to overflow the main jvm stack. Some other issue is occurring in the code causing too much data to be pushed. Possible a recursive call? Increasing the runtime stack size is just masking the problem.

tlf30 on Jul 23, 2017

It seems I was looking at different code. I am unable to run it at the moment.

Looking at the stack trace properly, which I have seen many times before from the scala compiler, the ultimate cause is that the type-inferencer is crashing due to a program that is not type-checking. This can be resolved by starting again, and slowly introducing type-checking expressions, making sure to ascribe a type to every expression along the way (do not rely on the inferencer). You will end up finding the expression that is crashing the type-checker.

@tlf30 I too, have worked on these programs 😃

tonymorris on Jul 24, 2017

@tonymorris, I would like to point out that @lare96 has already confirmed that it is not an issue with Rational, specifically the gcd(int, int) in io.luna.util.Rational? Some simple testing to confirm: commenting out that line and replacing the references to it with 1, still causes the stack overflow. Also I do not see how it is recursive. Look at the javap output:

private int gcd(int, int);
    Code:
       0: iload_1
       1: i2l
       2: invokestatic  #24                 // Method java/math/BigInteger.valueOf:(J)Ljava/math/BigInteger;
       5: astore_3
       6: iload_2
       7: i2l
       8: invokestatic  #24                 // Method java/math/BigInteger.valueOf:(J)Ljava/math/BigInteger;
      11: astore        4
      13: aload_3
      14: aload         4
      16: invokevirtual #25                 // Method java/math/BigInteger.gcd:(Ljava/math/BigInteger;)Ljava/math/BigInteger;
      19: invokevirtual #26                 // Method java/math/BigInteger.intValue:()I
      22: ireturn

@lare96 I would also like to take note that a looped approach for this function such as (I think you had something like this before)

private int gcd(int num0, int num1) {
        if (num0 == 0) {
            return num1;
        }

        while (num1 != 0) {
            if (num0 > num1) {
                num0 = num0 - num1;
            } else {
                num1 = num1 - num0;
            }
        }

        return num0;
    }

The stack overflow still occurs (as I said, I do not think the issue is here), and is also non-recursive. Also it is possible that this approach is faster as it does not have any object creation, but I have not tested that to confirm.

@tonymorris, I think you misunderstood me. I was trying to say that one of the only times a small program should have a stack overflow on the calling stack is when a recursive call occurs. I have worked on much larger enterprise java applications where the calling stack is upwards of 4GB without recursion, simply because so many functions are on the stack at a time, on those applications it is common to have stack overflows on the calling stack if the JVM is not properly configured.

tlf30 on Jul 24, 2017