Eclipse 4.6.1 hangs during content assitent on static methods on not yet imported classes #234
Comments
|
The issue in TypeSystem should not be contributing to the freeze...there are some patches in that class to help with the arrray OOB, but it is not a resolved issue as you can see. The concurrent mod exception is probably what is causing the freeze. Here are the relevant methods starting from DSLDStore and working up the stack. Best I can tell, there are no modifications of the lists created by FilteringPointcut.explodeObject. But there does appear to be two simultaneous iterations. /**
* Find all contributions for this pattern and this declaring type.
*
* @param pattern The pattern to match against
* @param disabledScripts The set of scripts that are disabled and should be ignored
* @return The set of contributions applicable for the pattern
*/
public List<IContributionElement> findContributions(GroovyDSLDContext pattern, Set<String> disabledScripts) {
List<IContributionElement> elts = new ArrayList<IContributionElement>();
synchronized (pointcutContributionMap) {
for (Map.Entry<IPointcut, List<IContributionGroup>> entry : pointcutContributionMap.entrySet()) {
IPointcut pointcut = entry.getKey();
if (!disabledScripts.contains(DSLDStore.toUniqueString(pointcut.getContainerIdentifier()))) {
pattern.resetBinding();
144: Collection<?> results = pointcut.matches(pattern, pattern.getCurrentType());
if (results != null) {
for (IContributionGroup group : entry.getValue()) {
elts.addAll(group.getContributions(pattern, pattern.getCurrentBinding()));
}
}
}
}
}
return elts;
}
@Override
public Collection<?> matches(GroovyDSLDContext pattern, Object toMatch) {
Object firstArgument = getFirstArgument();
ClassNode currentType = pattern.getCurrentType();
if (firstArgument instanceof String) {
if (currentType.getName().equals(firstArgument)) {
return Collections.singleton(currentType);
} else {
return null;
}
} else if (firstArgument instanceof Class<?>) {
if (currentType.getName().equals(((Class<?>) firstArgument).getName())) {
return Collections.singleton(currentType);
} else {
return null;
}
} else if (firstArgument != null) {
// we know this is a pointcut argument
061: return matchOnPointcutArgument((IPointcut) firstArgument, pattern, Collections.singleton(currentType));
} else {
// always match if there is no argument
return Collections.singleton(currentType);
}
}
protected Collection<?> matchOnPointcutArgument(IPointcut argument, GroovyDSLDContext pattern, Collection<?> allElementsToMatch) {
if (allElementsToMatch == null) {
return null;
}
Collection<Object> outerResults = new LinkedHashSet<Object>();
for (Object toMatch : allElementsToMatch) {
119: Collection<?> innerResults = argument.matches(pattern, toMatch);
if (innerResults != null) {
String bindingName = getArgumentName(argument);
if (bindingName != null) {
pattern.addToBinding(bindingName, innerResults);
}
outerResults.add(toMatch);
}
}
// return null if no matches found
return outerResults.size() > 0 ? outerResults : null;
}
@Override
public Collection<?> matches(GroovyDSLDContext pattern, Object toMatch) {
Collection<T> explodedList = explodeObject(toMatch);
if (explodedList == null || explodedList.size() == 0) {
return null;
}
Object first = getFirstArgument();
if (first instanceof IPointcut) {
// pass the exploded list to the inner pointcut and match on each element of the list
057: return matchOnPointcutArgument((IPointcut) first, pattern, explodedList);
} else {
059: Collection<?> filtered = filterResult(explodedList, pattern);
if (filtered != null) {
return filtered;
}
return null;
}
}
protected Collection<?> filterResult(Collection<T> results, GroovyDSLDContext context) {
Object o = getFirstArgument();
String firstArg = asString(o);
Collection<T> filtered = new ArrayList<T>(results.size());
071: for (T obj : results) {
T maybe = filterObject(obj, context, firstArg);
if (maybe != null) {
filtered.add(maybe);
}
}
return reduce(filtered);
}
protected Collection<T> explodeObject(Object toMatch) {
if (toMatch instanceof Collection<?>) {
List<T> objs = new ArrayList<T>();
for (Object elt : (Collection<?>) toMatch) {
if (filterBy.isInstance(elt)) {
objs.add((T) elt);
}
}
if (objs.size() > 0) {
return objs;
}
} else if (filterBy.isInstance(toMatch)) {
return Collections.singletonList((T) toMatch);
}
return null;
} |
|
One additional note, explodeObject is overridden by several sub-types of FilteringPointcut. That is likely where the con mod ex is coming from. Not all paths return a new collection. |
eric-milles
added a commit
that referenced
this issue
Nov 28, 2016
|
Updated snapshot should be available. Could you recheck? I think one of the collections (fields, methods, properties) from the type is being lazily loaded as the DSL job is accessing them. I made sure any collection read under FilteringPointcut is a copy; that should reduce the chance for a concurrent mod exception. |
|
..well, the hang is still there, the concurrent modification exception is gone, but eclipse still hangs.... |
|
I try to isolate the problem, but without luck at the moment, I got a new exception: |
|
Thanks for catching that. There must be more than one thread trying to put a value. setNodeMetaData checks that the value was null in the map; putNodeMetaData can be used instead. |
eric-milles
added a commit
that referenced
this issue
Dec 2, 2016
eric-milles
added a commit
that referenced
this issue
Dec 2, 2016
|
Can you retest with the latest snapshot? |
|
...well, the exceptions are gone, but we still have the eclipse hang during QuickFix/organize import/moving the mouse pointer over the unkown class,...in the profiler we see it hangs somewhere in: GroovyQuickFixProcessor.getCorrections() ...I try to checkout the grovvy plugin source code to debug... |
|
If you wait, does the content assist ever return? I have found that the first type search on an un-indexed project can take at least 8 seconds. |
|
Well not so easy to say. On my slow notebook, I can't reproduce it so good. On a fast PC, there we can reproduce it always. If you click somewhere in eclipse, then it is over. Moving the pointer out of the eclipse window, it could happen, that it returns and all is fine...strange and without an exception a difficult bug |
|
OK, I debug a little bit, and during the first start of the project I could reproduce it a little bit, the second start all was fine. It seems it has something to do with the paralell indexing. I stopped in the debugger and the two threads working and perhaps blocking each other are: and the other one: |
|
The second thread you list is an indexer thread. The other thread is waiting for the indexer to complete so it can suggest missing imports. Do you find that the indexer thread is not making progress? |
|
I debugged a little more, yes the indexer thread is not making progress and blocks the UI. It seems working infinite in the add/rehash Method of SimpleWordSet. I my case, after a size of 1769469 it seems looping/working infinite. |
|
Can you see what document is being parsed by BinaryIndexer/JavaSearchDocument? And can you say what jar is being precessed by AddJarFileToIndex? |
|
Yep, it is the jar file containing our database Layer, a very big one, but the indexer never comes back. I have uploaded the jar, so you can debug the process hopefully better. Without the Groovy Plugin installed, the indexer has no problems. |
|
Thanks for doing some extra digging. Would you mind creating a very simple project that recreates your issue? That way I could load it into my workspace and try the same steps as you. Also, have you tried the new Eclipse 4.7rc3 release? There is a new form of indexing and I am curious if the problem persists under the new indexing scheme. |
|
So here's what I did and had no issues. Hovering on the unresolved type gives me one completion immediately.
|
|
Well, the problem seems not isolatable. Bad. I get an infinite loop/hang with the new plugin..I retried Eclipse 4.5/4.6 and even 4.7M4, I always get the hang: https://drive.google.com/uc?id=0B1EIYV0ihMjCZFVPMjBUWmQzdWs With Eclipse 4.7M4 the same hang in SimpleWordSet (but I installed the 4.6 plugin, which perhaps don't use the new indexing?): It seems I have to add debug output to see, what is happening... ;-( |
|
Well, I think the problem exists, if the Eclipse index get trashed and needed to be completely rebuilded, e.g. upgrading to a new Eclipse version or deleting in the workspace the directory ".metadata\.plugins\org.eclipse.jdt.core". For large projects, like ours, this could be really time consuming. My workspace need 45 minutes for the index to build up. And the groovy quick fix then blocks the main eclipse thread: The problem seems in the class TypeSearch method searchForTypes running in the Eclipse main thread. There is the line The WAIT_UNTIL_READY_TO_SEARCH seems the problem, for me it is 45 minutes, and also the eclipse main thread is blocked. It would be better to stop the quick fix and tell the user it is not available at the moment because the index is build in the background. try it later. After 45 minutes all work fine, no eclipse hangs ;-) |
|
That seems sensible. I can see about tying the TypeSearch request into the progress monitor of the content assist and then you should get a progress dialog after a couple seconds with the option to cancel. |
|
OK, this would be helpfull. At the moment it is not usable for us, when the complete index is rebuilded. |
eric-milles
added a commit
that referenced
this issue
Jan 6, 2017
|
Could you try with the latest snapshot? |
|
Nope, eclipse is really strange. It still hangs: Your code change to FORCE_IMMEDIATE_SEARCH is also blocked by eclipse in the class ReadWriteMonitor and method enterRead, wich is asked if a read is allowed in the curent state. It seems it is not, so it is blocked. Changing to policy IJavaSearchConstants.CANCEL_IF_NOT_READY_TO_SEARCH fixes the problem for me. |
eric-milles
added a commit
that referenced
this issue
Jan 7, 2017
|
Thanks a lot, now we can finally use it. Any user info, that the quick fix and the full content assistent will be available when the indexer is ready would be helpfull. At the moment the user has no quick fix and only the default groovy methods are shown in the content assistent when the indexer is running. But that's an improvement, the blocking was the important one! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
we can reproduce the hang during content assistent, it happens for us on a content assitent call on a helper class with CompileStatic that has some static methods. Entering the unkown class name and a valid static method name brings eclipse to freeze.
The plugin is the version: 2.9.2.xx-201611270046-e46
I have the following exceptions:
and the follwing:
Hope it helps to find the bug.
Cheers,
Marcel
The text was updated successfully, but these errors were encountered: