groovy
  1. groovy
  2. GROOVY-4803

out of memory error when running groovydoc when there are java files in packages

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.7.10, 1.8.0
    • Fix Version/s: 2.0-beta-3, 1.7.11, 1.8.7
    • Component/s: GroovyDoc, parser-antlr
    • Labels:
      None
    • Environment:
      mac os 10.6.7
      java 1.6.0_24
      groovy 1.8.0 (however same problem with 1.7.10)
    • Number of attachments :
      1

      Description

      reference: i found this bug running the ant task groovydoc; however, i then went to the command line to isolate the issue. i started with 1.7.10 and then upgraded to 1.8.0 and got the same error.

      this bug is repeatable.

      follow these steps:
      1) create a groovy project
      2) add a package with groovy classes
      3) run this command: rm -rf /tmp/docs/; mkdir -p /tmp/docs; groovydoc -verbose -private --destdir /tmp/docs <package name>
      4) everything should work fine
      5) add a java file to the package
      6) run this command: rm -rf /tmp/docs/; mkdir -p /tmp/docs; groovydoc -verbose -private --destdir /tmp/docs <package name>
      7) get an out of memory error when it hits the java file

      i think groovy is doing a reclusive call that never ends until it runs out of memory

      the project that i created using ant can be found at my github : https://github.com/matthewpurdy/purdyCommonTasks

      project directory structure looks like this:

      purdyCommonTasks/
      ├── README
      ├── build.properties
      ├── build.xml
      ├── lib/
      │   ├── groovy-all-1.8.0.jar
      │   ├── junit-4.8.1.jar
      │   └── log4j-1.2.16.jar
      ├── purdyCommonTasks.xml
      ├── resources/
      │   └── log4j.xml
      ├── src/
      │   └── somepackage/
      │   ├── Main.groovy
      │   ├── SomeClass.groovy
      │   └── SomeClass2.java
      └── test/
      └── somepackage/
      └── SomeClassTest.groovy

      results when i run it from the commandline:

      mpurdy-keywcorp:purdyCommonTasks mpurdy$ which groovy
      /usr/local/groovy/bin/groovy
      mpurdy-keywcorp:purdyCommonTasks mpurdy$ ls -l `which groovy`
      -rwxrwxr-x@ 1 root wheel 1.0K Apr 27 14:55 /usr/local/groovy/bin/groovy*
      mpurdy-keywcorp:purdyCommonTasks mpurdy$ ls -l /usr/local/groovy
      lrwxr-xr-x 1 root wheel 12B Apr 29 16:14 /usr/local/groovy@ -> groovy-1.8.0
      mpurdy-keywcorp:purdyCommonTasks mpurdy$ groovy -version
      Groovy Version: 1.8.0 JVM: 1.6.0_24
      mpurdy-keywcorp:purdyCommonTasks mpurdy$ rm -rf /tmp/docs/;mkdir -p /tmp/docs;groovydoc -verbose -private --destdir /tmp/docs -windowtitle mydocs somepackage `find src/* -type f`
      REDERROR [org.codehaus.groovy.tools.groovydoc.GroovyRootDocBuilder] Out of memory while processing: DefaultPackage/SomeClass2.java
      java.lang.reflect.InvocationTargetException
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:108)
      at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:130)
      Caused by: java.lang.OutOfMemoryError: Java heap space
      at antlr.ANTLRStringBuffer.append(ANTLRStringBuffer.java:36)
      at antlr.CharScanner.append(CharScanner.java:64)
      at antlr.CharScanner.consume(CharScanner.java:82)
      at antlr.CharScanner.match(CharScanner.java:205)
      at org.codehaus.groovy.antlr.java.JavaLexer.mSL_COMMENT(JavaLexer.java:1142)
      at org.codehaus.groovy.antlr.java.JavaLexer.nextToken(JavaLexer.java:401)
      at org.codehaus.groovy.antlr.java.JavaLexer$1.nextToken(JavaLexer.java:98)
      at antlr.TokenBuffer.fill(TokenBuffer.java:69)
      at antlr.TokenBuffer.LT(TokenBuffer.java:86)
      at antlr.LLkParser.LT(LLkParser.java:56)
      at org.codehaus.groovy.antlr.java.JavaRecognizer.classDefinition(JavaRecognizer.java:753)
      at org.codehaus.groovy.antlr.java.JavaRecognizer.typeDefinitionInternal(JavaRecognizer.java:674)
      at org.codehaus.groovy.antlr.java.JavaRecognizer.typeDefinition(JavaRecognizer.java:509)
      at org.codehaus.groovy.antlr.java.JavaRecognizer.compilationUnit(JavaRecognizer.java:348)
      at org.codehaus.groovy.tools.groovydoc.GroovyRootDocBuilder.parseJava(GroovyRootDocBuilder.java:86)
      at org.codehaus.groovy.tools.groovydoc.GroovyRootDocBuilder.getClassDocsFromSingleSource(GroovyRootDocBuilder.java:70)
      at org.codehaus.groovy.tools.groovydoc.GroovyRootDocBuilder.processFile(GroovyRootDocBuilder.java:205)
      at org.codehaus.groovy.tools.groovydoc.GroovyRootDocBuilder.buildTree(GroovyRootDocBuilder.java:162)
      at org.codehaus.groovy.tools.groovydoc.GroovyDocTool.add(GroovyDocTool.java:66)
      at org.codehaus.groovy.tools.groovydoc.GroovyDocTool$add.call(Unknown Source)
      at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
      at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
      at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
      at org.codehaus.groovy.tools.groovydoc.Main.execute(Main.groovy:198)
      at org.codehaus.groovy.tools.groovydoc.Main.main(Main.groovy:168)
      ... 6 more
      mpurdy-keywcorp:purdyCommonTasks mpurdy$

        Activity

        Hide
        Paul King added a comment - - edited

        I can reproduce the problem. If I add an end of line to the end of the Java file, the problem goes away. So I guess that is the workaround.

        Yes, groovydoc is using a Java grammar which I don't believe is specially modified since we got it. Maybe we have to modify it or some other end of file trick to overcome this problem.

        Show
        Paul King added a comment - - edited I can reproduce the problem. If I add an end of line to the end of the Java file, the problem goes away. So I guess that is the workaround. Yes, groovydoc is using a Java grammar which I don't believe is specially modified since we got it. Maybe we have to modify it or some other end of file trick to overcome this problem.
        Hide
        Matthew Purdy added a comment -

        thanx; that works for me

        maybe it should be noted in the docs that you must add a 0x10 to the end of each java file before running groovydocs over that package.

        Show
        Matthew Purdy added a comment - thanx; that works for me maybe it should be noted in the docs that you must add a 0x10 to the end of each java file before running groovydocs over that package.
        Hide
        Paul King added a comment -

        Just for the record (at least until we find a better fix) it is only Java files that have no end-of-line (i.e. no appropriate CR/LF for platform) that also have a single-line (double slash) comment on that last line that have this problem. The Antlr Java parser is looking for a CR and/or LF to close off the single-line comment and never finds it.

        Show
        Paul King added a comment - Just for the record (at least until we find a better fix) it is only Java files that have no end-of-line (i.e. no appropriate CR/LF for platform) that also have a single-line (double slash) comment on that last line that have this problem. The Antlr Java parser is looking for a CR and/or LF to close off the single-line comment and never finds it.
        Hide
        blackdrag blackdrag added a comment -

        Paul, I cannot reproduce the issue. I found in the grammar a change. It references to GROOVY-766 and would be about this:

         // Single-line comments
         SL_COMMENT
                :       "//"
        -               (~('\n'|'\r'))* ('\n'|'\r'('\n')?)
        +        (
        +            options {  greedy = true;  }:
        +            // '\uffff' means the EOF character.
        +            ~('\n'|'\r'|'\uffff')
        +        )*
                        {$setType(Token.SKIP); newline();}
                ;
        


        can you test this?

        Show
        blackdrag blackdrag added a comment - Paul, I cannot reproduce the issue. I found in the grammar a change. It references to GROOVY-766 and would be about this: // Single-line comments SL_COMMENT : " //" - (~('\n'|'\r'))* ('\n'|'\r'('\n')?) + ( + options { greedy = true ; }: + // '\uffff' means the EOF character. + ~('\n'|'\r'|'\uffff') + )* {$setType(Token.SKIP); newline();} ; can you test this?
        Hide
        Paul King added a comment -

        Indeed, that fixes the problem.

        Show
        Paul King added a comment - Indeed, that fixes the problem.
        Hide
        blackdrag blackdrag added a comment -

        I applied the fix

        Show
        blackdrag blackdrag added a comment - I applied the fix

          People

          • Assignee:
            blackdrag blackdrag
            Reporter:
            Matthew Purdy
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: