StackOverflow in Java Analyzer

[Andreas Mandel]

Hi,

I've a java.lang.StackOverflowError to report while scanning a wired java class (SQ5.6 / Java 4.0). I agree that this code is far from being ok, but IMHO it should not break the SQ run.

package com.example.sonarqube;

public class StackOverflow {

    public static final String SAMPLE = "SAMPLE";

    public String sampleMethod() {
        final StringBuffer sb = new StringBuffer();
        sb.append(SAMPLE)
                .append(SAMPLE)
                .append(SAMPLE)
// same line 1000 times
                .append(SAMPLE);
        return sb.toString();
    }
}

The system is out of resources.
Consult the following stack trace for details.
java.lang.StackOverflowError
at com.sun.tools.javac.comp.Check.checkType(Check.java:533)
at com.sun.tools.javac.comp.Attr$ResultInfo.check(Attr.java:476)
at com.sun.tools.javac.comp.Attr.check(Attr.java:275)
at com.sun.tools.javac.comp.Attr.checkIdInternal(Attr.java:3618)
at com.sun.tools.javac.comp.Attr.checkId(Attr.java:3466)
at com.sun.tools.javac.comp.Attr.visitIdent(Attr.java:3209)
at com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2011)
at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:566)
at com.sun.tools.javac.comp.Attr.attribArgs(Attr.java:664)
at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1806)
at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1465)
at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:566)
at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3226)
at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1897)
at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:566)
// lot of lines deleted
at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1815)
at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1465)
at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:566)
at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3226)
at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1897)
at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:566)
at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1815)

BTW might be a thing to consider at https://groups.google.com/forum/#!topic/sonarqube/F40LVP7W1us


Kind Regards,
Andreas.

[Nicolas Peru]

Hi Andreas, 

From the stacktrace, the SOE you are reporting is on javac, ie : this happens during the compilation of your project. So I guess this code is actually not ok at all since it will not compile. 

The sonar java analyzer assumes that the code you are passing to it went through compilation phase ok. 

Cheers, 

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/7186dd1f-1739-46f8-aa96-2d6326398eab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Nicolas PERU | SonarSource

Senior Developer
http://sonarsource.com

https://twitter.com/benzonico

[Andreas Mandel]

Hi Nicolas,

oh -you are right. I tried to reproduce a actual case but failed. I'll come up with the real stack trace.

Kind Regards,
Andreas.

[Andreas Mandel]

Hi Nicolas,

OK here the actual stack trace:

[ERROR] A stack overflow error occured while analyzing file: .../src/main/java/com/example/sonarqube/StackOverflow.java
Exception in thread "main" java.lang.StackOverflowError
    at org.sonar.java.resolve.JavaSymbol$TypeJavaSymbol.members(JavaSymbol.java:349)
    at org.sonar.java.resolve.Resolve.findField(Resolve.java:113)
    at org.sonar.java.resolve.Resolve.findVar(Resolve.java:155)
    at org.sonar.java.resolve.Resolve.findIdent(Resolve.java:284)
    at org.sonar.java.resolve.TypeAndReferenceSolver.resolveAs(TypeAndReferenceSolver.java:340)
    at org.sonar.java.resolve.TypeAndReferenceSolver.resolveAs(TypeAndReferenceSolver.java:319)
    at org.sonar.java.resolve.TypeAndReferenceSolver.resolveAs(TypeAndReferenceSolver.java:312)
    at org.sonar.java.resolve.TypeAndReferenceSolver.visitIdentifier(TypeAndReferenceSolver.java:836)
    at org.sonar.java.model.expression.IdentifierTreeImpl.accept(IdentifierTreeImpl.java:81)
    at org.sonar.java.ast.parser.ListTreeImpl.accept(ListTreeImpl.java:63)
    at org.sonar.plugins.java.api.tree.BaseTreeVisitor.scan(BaseTreeVisitor.java:43)
    at org.sonar.plugins.java.api.tree.BaseTreeVisitor.scan(BaseTreeVisitor.java:48)
    at org.sonar.java.resolve.TypeAndReferenceSolver.visitMethodInvocation(TypeAndReferenceSolver.java:221)
    at org.sonar.java.model.expression.MethodInvocationTreeImpl.accept(MethodInvocationTreeImpl.java:82)
    at org.sonar.java.resolve.TypeAndReferenceSolver.resolveAs(TypeAndReferenceSolver.java:349)
    at org.sonar.java.resolve.TypeAndReferenceSolver.resolveAs(TypeAndReferenceSolver.java:319)
    at org.sonar.java.resolve.TypeAndReferenceSolver.resolveAs(TypeAndReferenceSolver.java:312)
    at org.sonar.java.resolve.TypeAndReferenceSolver.resolveMethodSymbol(TypeAndReferenceSolver.java:289)
    at org.sonar.java.resolve.TypeAndReferenceSolver.visitMethodInvocation(TypeAndReferenceSolver.java:225)
    at org.sonar.java.model.expression.MethodInvocationTreeImpl.accept(MethodInvocationTreeImpl.java:82)
    ...

Might be it makes sense to stop after a nesting of 500(?) or even before and mark the source as sth like "to wired to be analyzed for obvious reasons".

Kind Regards,
Andreas.


Am Donnerstag, 21. Juli 2016 15:09:37 UTC+2 schrieb Nicolas Peru: