Bugzilla – Full Text Bug Listing
| Summary: | [formatter] Running from command line on many files causes ArrayIndexOutOfBoundsException | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Doug Simon <doug.simon> |
| Component: | Core | Assignee: | Jesper Moller <jesper> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | daniel_megert, jarthana, srikanth_sankaran |
| Version: | 4.3 | ||
| Target Milestone: | 4.3 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
Jesper, please take a look: if fix is straightforward, we can consider for Kepler M7. A little further inspection shows that this is not related to the number of files being formatted; it's something about the specific content of a file being processed. For example, processing the following file alone triggers the exception: http://hg.openjdk.java.net/graal/graal/raw-file/698cd036a1ca/graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Parser.java The configuration being used is here: http://hg.openjdk.java.net/graal/graal/raw-file/1ca1425a067f/mx/eclipse-settings/org.eclipse.jdt.core.prefs (In reply to comment #2) > A little further inspection shows that this is not related to the number of > files being formatted; it's something about the specific content of a file > being processed. For example, processing the following file alone triggers > the exception: The 183rd file, I suppose ;-) The problem is a combination of the number of changes in a file and the sequence of files, and a lack of test when appending to the array, as you suggested. Thank you very much for isolating this. Do we have a workaround for this? If not and if the fix is straight forward, we can consider it for RC1. (In reply to comment #4) > Do we have a workaround for this? If not and if the fix is straight forward, > we can consider it for RC1. Please check: - Is this a regression? If so, since which release. - Does it work, if one creates a Java project that has this source? If so, this would be a possible workaround. (In reply to comment #5) > Please check: > - Is this a regression? If so, since which release. > - Does it work, if one creates a Java project that has this source? If so, > this would be a possible workaround. Jesper, since you probably have the set-up to reproduce this already, could you please respond to this? Thanks! It's a regression since Indigo, it seems. - Reproduced in 3.8.2 and 3.7.2 - Not reproducible in 3.6.2 - Formatting from within an Eclipse workspace gives same error (In reply to comment #7) > It's a regression since Indigo, it seems. > - Reproduced in 3.8.2 and 3.7.2 - Not reproducible in 3.6.2 > - Formatting from within an Eclipse workspace gives same error This qualifies for a fix in RC1 or RC2, if we can find a low risk fix. I cannot reproduce this in Kepler RC1, but can in Juno, so it appears to be fixed. Doug, could you try this again in the latest and greatest Eclipse? It works fine now in my environment. Thanks. Ok, I'm going to close it, then. Thanks for reporting. |
When using the formatter from the command line on a large number of files, an ArrayIndexOutOfBoundsException is thrown by the formatter. Here's the contents of the log file denoted by the resulting error dialog: !SESSION 2013-04-09 21:49:29.546 ----------------------------------------------- eclipse.buildId=M20130204-1200 java.version=1.7.0_15 java.vendor=Oracle Corporation BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US Framework arguments: -application org.eclipse.jdt.core.JavaCodeFormatter -config [elided about 190 more arguments] Command-line arguments: -os linux -ws gtk -arch x86_64 -application org.eclipse.jdt.core.JavaCodeFormatter -config [elided about 190 more arguments] !ENTRY org.eclipse.osgi 4 0 2013-04-09 21:49:31.580 !MESSAGE Application error !STACK 1 java.lang.ArrayIndexOutOfBoundsException: 100 at org.eclipse.jdt.internal.formatter.Scribe.printNewLinesCharacters(Scribe.java:4867) at org.eclipse.jdt.internal.formatter.Scribe.addOptimizedReplaceEdit(Scribe.java:571) at org.eclipse.jdt.internal.formatter.Scribe.addReplaceEdit(Scribe.java:663) at org.eclipse.jdt.internal.formatter.Scribe.printComment(Scribe.java:2553) at org.eclipse.jdt.internal.formatter.Scribe.printComment(Scribe.java:2406) at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.visit(CodeFormatterVisitor.java:4379) at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.traverse(MethodDeclaration.java:277) at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.format(CodeFormatterVisitor.java:593) at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.formatTypeMembers(CodeFormatterVisitor.java:2212) at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.format(CodeFormatterVisitor.java:1217) at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.visit(CodeFormatterVisitor.java:5586) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.traverse(TypeDeclaration.java:1286) at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.visit(CodeFormatterVisitor.java:3305) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.traverse(CompilationUnitDeclaration.java:679) at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.format(CodeFormatterVisitor.java:863) at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.formatCompilationUnit(DefaultCodeFormatter.java:241) at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.format(DefaultCodeFormatter.java:163) at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.format(DefaultCodeFormatter.java:146) at org.eclipse.jdt.core.formatter.CodeFormatterApplication.formatFile(CodeFormatterApplication.java:223) at org.eclipse.jdt.core.formatter.CodeFormatterApplication.start(CodeFormatterApplication.java:418) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584) at org.eclipse.equinox.launcher.Main.run(Main.java:1438) at org.eclipse.equinox.launcher.Main.main(Main.java:1414) The command I run is: ~/eclipse-4.2/eclipse -nosplash -application org.eclipse.jdt.core.JavaCodeFormatter -config ... In my particular case, it crashes when there are 183 or more files. This seems like a simple case of not checking the current size of the Scribe.edits array before appending to it.