Comment 1 Andrey Loskutov 2021-01-22 11:55:51 EST

This is most likely the regression from bug 567521.
I assume if you disable parallel index search, it will work again.
From the stack trace looks like the caller passed progress monitor to JDT search that can only be used from UI thread (EventLoopProgressMonitor). If given to parallel instances, the monitor fails to work.

Can you please provide simpler steps to reproduce (without xtext)?

Comment 2 Kalyan Prasad Tatavarthi 2021-01-27 02:59:21 EST

Moving to JDT Core as PatternSearchJob is part of JDT Core.

Comment 3 Christian Dietrich 2021-01-27 03:28:46 EST

unforunately i have no idea how to strip down this to a simple example

Comment 4 Christian Dietrich 2021-01-27 03:38:21 EST

our progress monitor is replace with the eventloop one at
org.eclipse.ui.actions.WorkspaceModifyOperation.run(IProgressMonitor)

Comment 5 Christian Dietrich 2021-01-27 03:39:01 EST

more main stacktrace:

Object.wait(long) line: not available [native method]	
ForkJoinTask$AdaptedCallable<T>(ForkJoinTask<V>).externalInterruptibleAwaitDone() line: 356	
ForkJoinTask$AdaptedCallable<T>(ForkJoinTask<V>).get() line: 1004	
SubTypeSearchJob(PatternSearchJob).performParallelSearch(Index[], SubMonitor) line: 136	
SubTypeSearchJob(PatternSearchJob).execute(IProgressMonitor) line: 97	
IndexManager(JobManager).performConcurrentJob(IJob, int, IProgressMonitor) line: 265	
IndexBasedHierarchyBuilder.legacySearchAllPossibleSubTypes(IType, IJavaSearchScope, Map, IPathRequestor, int, IProgressMonitor) line: 678	
IndexBasedHierarchyBuilder.searchAllPossibleSubTypes(IType, IJavaSearchScope, Map, IPathRequestor, int, IProgressMonitor) line: 514	
IndexBasedHierarchyBuilder.determinePossibleSubTypes(HashSet, IProgressMonitor) line: 466	
IndexBasedHierarchyBuilder.build(boolean) line: 159	
TypeHierarchy.compute() line: 323	
TypeHierarchy.refresh(IProgressMonitor) line: 1319	
CreateTypeHierarchyOperation.executeOperation() line: 94	
CreateTypeHierarchyOperation(JavaModelOperation).run(IProgressMonitor) line: 740	
CreateTypeHierarchyOperation(JavaModelOperation).runOperation(IProgressMonitor) line: 806	
SourceType.newTypeHierarchy(WorkingCopyOwner, IProgressMonitor) line: 950	
SourceType.newTypeHierarchy(IProgressMonitor) line: 907	
RenameVirtualMethodProcessor.getCachedHierarchy(IType, IProgressMonitor) line: 100	
RenameVirtualMethodProcessor.checkInitialConditions(IProgressMonitor) line: 126	
CombinedJvmJdtRenameProcessor.checkInitialConditions(IProgressMonitor) line: 117	
ChangeCombiningRenameRefactoring(ProcessorBasedRefactoring).checkInitialConditions(IProgressMonitor) line: 207	
ChangeCombiningRenameRefactoring(Refactoring).checkAllConditions(IProgressMonitor) line: 161	
AbstractXtendRenameRefactoringTest$1.execute(IProgressMonitor) line: 158	
AbstractXtendRenameRefactoringTest$1(WorkspaceModifyOperation).lambda$0(InvocationTargetException[], IProgressMonitor) line: 110	
1901662085.run(IProgressMonitor) line: not available	
Workspace.run(ICoreRunnable, ISchedulingRule, int, IProgressMonitor) line: 2292	
Workspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) line: 2317	
AbstractXtendRenameRefactoringTest$1(WorkspaceModifyOperation).run(IProgressMonitor) line: 131	
JavaRefactoringIntegrationTest(AbstractXtendRenameRefactoringTest).renameXtendElement(XtextEditor, int, String, int, IProgressMonitor) line: 163	
JavaRefactoringIntegrationTest(AbstractXtendRenameRefactoringTest).renameXtendElement(XtextEditor, int, String, int) line: 147	
JavaRefactoringIntegrationTest.testRenameXtendDispatchMethod_1() line: 530	
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62	
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43	
Method.invoke(Object, Object...) line: 566	
FrameworkMethod$1.runReflectiveCall() line: 59	
FrameworkMethod$1(ReflectiveCallable).run() line: 12	
FrameworkMethod.invokeExplosively(Object, Object...) line: 56	
InvokeMethod.evaluate() line: 17	
RunBefores.evaluate() line: 26	
RunAfters.evaluate() line: 27	
ParentRunner$3.evaluate() line: 306	
BlockJUnit4ClassRunner$1.evaluate() line: 100

Comment 6 Andrey Loskutov 2021-01-27 05:59:00 EST

With EventLoopProgressMonitor given to PatternSearchJob we have no chance, we can't use it for single tasks. I will push a patch which I'm not really like, but I don't see a good solution now, especially in jdt core we can't check if we are in UI thread or not because we don't have Display access at all.

@Mickael, I believe in the context of the async context assist you had similar issue? Any elegant way to solve it?

I will push patch proposal in a second.

Comment 7 Eclipse Genie 2021-01-27 05:59:54 EST

New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/175402

Comment 8 Andrey Loskutov 2021-01-27 06:09:41 EST

(In reply to Christian Dietrich from comment #3)
> unforunately i have no idea how to strip down this to a simple example

Can a *real* user trigger this from UI, or is this "only" a test issue in Xtext, because the tests run in UI thread? Just trying to understand how likely we will see that in real life / if the proposed patch really urgently needed.

I see that WorkspaceModifyOperation only supplies EventLoopProgressMonitor if it is running in UI thread, which is probably not a good idea anyway (workspace operations may block), and which is why it is probably not often used this way.

One possible workaround for Xtext test (until we will have agreement on right fix) would to either use non UI thread to run or to switch off parallel build.

Comment 9 Christian Dietrich 2021-01-27 06:11:16 EST

will check the patch.
will also check what happens when
you start rename refactoring from 
eclipse. the main problem is how to get the project
into the same state as it is in eclipse.

Comment 10 Christian Dietrich 2021-01-27 06:20:59 EST

patch looks good, but i dont get it reproduced with refactoring in ui.
i assume this is indeed cause by our test to run a workspacemodifyop from the test code.

Comment 11 Eclipse Genie 2021-01-27 06:47:50 EST

New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/175403

Comment 12 Mickael Istria 2021-01-27 07:32:53 EST

(In reply to Andrey Loskutov from comment #6)
> @Mickael, I believe in the context of the async context assist you had
> similar issue? Any elegant way to solve it?

For content-assist, we added a flag to the extension point to declare whether extension can run out of UI Thread or not and the consumer of the extension point deals with it accordingly.
I don't think it's very elegant; I think bug 548970 is what should in the end lead to something more elegant and more standard.

Comment 13 Christian Dietrich 2021-01-27 09:25:03 EST

2nd patch looks good too, from Xtext pov

Comment 14 Eclipse Genie 2021-01-27 11:49:21 EST

Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/175403 was merged to [master].
Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=1e70faf6e9d42ea13f06e076a7e7eda11c11be80

Comment 15 Andrey Loskutov 2021-01-27 11:51:56 EST

(In reply to Christian Dietrich from comment #13)
> 2nd patch looks good too, from Xtext pov

Patch is merged, please verify after next platform build tomorrow.

Comment 16 Christian Dietrich 2021-01-29 02:33:01 EST

looks good. problem is lo longer in our logs