Bugzilla – Full Text Bug Listing
| Summary: | ArrayOutOfBoundException while autocompleting a jar library with attached javadoc | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Alex Falappa <alex.falappa> |
| Component: | Core | Assignee: | Jay Arthanareeswaran <jarthana> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | daniel_megert, dirk.ziegenbalg, jarthana, javier.villa00, jritchey, manoj.palat, tparker |
| Version: | 4.3.1 | Flags: | jarthana:
review+
manoj.palat: review+ |
| Target Milestone: | 4.4 RC1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Alex Falappa
After additional investigation I've found that the mentioned exception does not occur in a normal java project and if the jooq jar is manually added to the build path. This may mean that the problem may lie in the plugin that manages Maven dependencies (m2e plugin?). Reassigning to m2e. Further investigation after upgrading to Kepler 4.3 SR1 and downgrading jdk to 7u25 to prevent other anomalies. The problem is not linked to maven projects, as it presents on normal java projects too, but to the presence of the javadoc attachment to the jooq library. If the javadoc attachment is removed completion works flawlessly. Reassigning to JDT. (In reply to Alex Falappa from comment #2) > Further investigation after upgrading to Kepler 4.3 SR1 and downgrading jdk > to 7u25 to prevent other anomalies. > > The problem is not linked to maven projects, as it presents on normal java > projects too, but to the presence of the javadoc attachment to the jooq > library. If the javadoc attachment is removed completion works flawlessly. I suspect that the attached Javadoc does not match the actual/binary code. Can you check that? Sorry for late feedback. At a first glance the javadoc jar content seems to correspond (you can download it at http://repo1.maven.org/maven2/org/jooq/jooq/3.1.0/jooq-3.1.0-javadoc.jar). As an additional note by attaching a remote javadoc to the jooq jar (pointing at http://www.jooq.org/javadoc/latest/) all works nicely. See bug 414024 comment 13 for a self-contained test case. *** Bug 414024 has been marked as a duplicate of this bug. *** I noticed this with a project including the google guava libraries and can confirm the relation with Javadocs: Bug happens with a user library configured with: JAR file: guava-16.0.1.jar Javadorc JAR file: guava-16.0.1-javadoc.jar Obtained from google at https://code.google.com/p/guava-libraries/ Removing the Javadoc caused the bug to stop happening. The issue here is an overly simplistic searching of Javadoc for the the function's parameter list. If you have a function signature like:
@GwtIncompatible("NavigableSet")
@SuppressWarnings("unchecked")
public static <E> NavigableSet<E> filter(
NavigableSet<E> unfiltered, Predicate<? super E> predicate) {
...
}
the generated Javadoc is:
<h4>filter</h4>
<pre><a href="../../../../com/google/common/annotations/GwtIncompatible.html" title="annotation in com.google.common.annotations">@GwtIncompatible</a>(<a href="../../../../com/google/common/annotations/GwtIncompatible.html#value()">value</a>="NavigableSet")
public static <E> java.util.NavigableSet<E> filter(java.util.NavigableSet<E> unfiltered,
<a href="../../../../com/google/common/base/Predicate.html" title="interface in com.google.common.base">Predicate</a><? super E> predicate)</pre>
The code in BinaryMethod.getParameterNames() near line 352 extracts parameters by searching for the first occurrence of "(", and thus extracts the single parameter to the first annotation, not the two parameters to the function. The array size mismatch is what causes the ArrayOutOfBoundException.
The second issue here is that once the runtime exception has been triggered, keyboard and mouse focus is lost, and the only recourse is to kill Eclipse. I'm not as sure about the best way to protect against that, but it looks like the problem is that org.eclipse.jface.text.contentassist.CompletionProposalPopup never unregisters its fFocusHelper. Perhaps that can be remedied by wrapping the call to handleSetData() in CompletionProposalPopup's SetData listener in a try/catch block, catching RuntimeException and invoking hide() before rethrowing the exception?
(In reply to Terry Parker from comment #8) > The issue here is an overly simplistic searching of Javadoc for the the > function's parameter list. If you have a function signature like: > > @GwtIncompatible("NavigableSet") > @SuppressWarnings("unchecked") > public static <E> NavigableSet<E> filter( > NavigableSet<E> unfiltered, Predicate<? super E> predicate) { > ... > } > > the generated Javadoc is: > <h4>filter</h4> > <pre><a > href="../../../../com/google/common/annotations/GwtIncompatible.html" > title="annotation in com.google.common.annotations">@GwtIncompatible</a>(<a > href="../../../../com/google/common/annotations/GwtIncompatible. > html#value()">value</a>="NavigableSet") > public > static <E> java.util.NavigableSet<E> filter(java. > util.NavigableSet<E> unfiltered, > <a > href="../../../../com/google/common/base/Predicate.html" title="interface in > com.google.common.base">Predicate</a><? super E> predicate)</pre> > > The code in BinaryMethod.getParameterNames() near line 352 extracts > parameters by searching for the first occurrence of "(", and thus extracts > the single parameter to the first annotation, not the two parameters to the > function. The array size mismatch is what causes the > ArrayOutOfBoundException. > > The second issue here is that once the runtime exception has been triggered, > keyboard and mouse focus is lost, and the only recourse is to kill Eclipse. > I'm not as sure about the best way to protect against that, but it looks > like the problem is that > org.eclipse.jface.text.contentassist.CompletionProposalPopup never > unregisters its fFocusHelper. Perhaps that can be remedied by wrapping the > call to handleSetData() in CompletionProposalPopup's SetData listener in a > try/catch block, catching RuntimeException and invoking hide() before > rethrowing the exception? I filed bug 429925: "Protect against poorly behaved completion proposers" with a suggested patch for the second issue. *** Bug 432941 has been marked as a duplicate of this bug. *** Looks like this has always been around and not sure if we have the time to take this up for Luna. Moving to 4.5. (In reply to Jayaprakash Arthanareeswaran from comment #11) > Looks like this has always been around and not sure if we have the time to > take this up for Luna. Moving to 4.5. I pushed up a patch for review at: https://git.eclipse.org/r/#/c/26082 Jay, please take a look at the patch during RC1. Patch looks good. One issue I found is, I can trick the code into failing by having something like this for the annotation value:
value="test)>filter<("
But I think the odds of someone using such code is very little.
Thanks Manoj, the fix is in master now: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=1d3546ae21ffe0ff967875f1cabb468e47817326 (In reply to Jayaprakash Arthanareeswaran from comment #15) > Thanks Manoj, the fix is in master now: > > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=1d3546ae21ffe0ff967875f1cabb468e47817326 Thanks for the review, Jay. Verified for Luna 4.4 RC1 Build id: I20140518-2000 |