groovy

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

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
Paul King added a comment -

Indeed, that fixes the problem.

Show
Paul King added a comment - Indeed, that fixes the problem.
Hide
Permalink
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
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: