Skip to content
This repository has been archived by the owner on Apr 21, 2023. It is now read-only.

Exception: An internal error occurred during: "calculating highlighting". #1389

Closed
miklossy opened this issue Apr 4, 2020 · 27 comments
Closed
Assignees
Milestone

Comments

@miklossy
Copy link
Contributor

miklossy commented Apr 4, 2020

Just hit the following exception while implementing the Xtext Domainmodel Tutorial:

  • Eclipse 2020-03
  • Xtext 2.22.0.v20200404-0123

image

java.lang.RuntimeException: org.eclipse.xtext.service.OperationCanceledError: org.eclipse.core.runtime.OperationCanceledException
	at org.eclipse.xtext.resource.OutdatedStateManager.exec(OutdatedStateManager.java:71)
	at org.eclipse.xtext.ui.editor.model.XtextDocument$XtextDocumentLocker.internalReadOnly(XtextDocument.java:525)
	at org.eclipse.xtext.ui.editor.model.XtextDocument$XtextDocumentLocker.readOnly(XtextDocument.java:497)
	at org.eclipse.xtext.ui.editor.model.XtextDocument.readOnly(XtextDocument.java:136)
	at org.eclipse.xtext.util.concurrent.IReadAccess.tryReadOnly(IReadAccess.java:50)
	at org.eclipse.xtext.util.concurrent.IReadAccess.tryReadOnly(IReadAccess.java:71)
	at org.eclipse.xtext.ui.editor.syntaxcoloring.HighlightingReconciler$2.run(HighlightingReconciler.java:352)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: org.eclipse.xtext.service.OperationCanceledError: org.eclipse.core.runtime.OperationCanceledException
	at org.eclipse.xtext.service.OperationCanceledManager.asWrappingOperationCanceledException(OperationCanceledManager.java:72)
	at org.eclipse.xtext.service.OperationCanceledManager.throwOperationCanceledException(OperationCanceledManager.java:78)
	at org.eclipse.xtext.service.OperationCanceledManager.checkCanceled(OperationCanceledManager.java:87)
	at org.eclipse.xtext.xbase.resource.BatchLinkableResource.resolveLazyCrossReferences(BatchLinkableResource.java:168)
	at org.eclipse.xtext.xbase.resource.BatchLinkableResource.linkBatched(BatchLinkableResource.java:196)
	at org.eclipse.xtext.ui.editor.syntaxcoloring.HighlightingReconciler.beforeRefresh(HighlightingReconciler.java:379)
	at org.eclipse.xtext.ui.editor.syntaxcoloring.HighlightingReconciler$2$1.exec(HighlightingReconciler.java:356)
	at org.eclipse.xtext.ui.editor.syntaxcoloring.HighlightingReconciler$2$1.exec(HighlightingReconciler.java:1)
	at org.eclipse.xtext.util.concurrent.CancelableUnitOfWork.exec(CancelableUnitOfWork.java:27)
	at org.eclipse.xtext.util.concurrent.WrappingCancelableUnitOfWork.exec(WrappingCancelableUnitOfWork.java:58)
	at org.eclipse.xtext.util.concurrent.CancelableUnitOfWork.exec(CancelableUnitOfWork.java:27)
	at org.eclipse.xtext.resource.OutdatedStateManager.exec(OutdatedStateManager.java:69)
	... 7 more
Caused by: org.eclipse.core.runtime.OperationCanceledException
	at org.eclipse.xtext.service.OperationCanceledManager.getPlatformSpecificOperationCanceledException(OperationCanceledManager.java:82)
	... 18 more
@miklossy
Copy link
Contributor Author

miklossy commented Apr 4, 2020

Could be something related to Xtend.

@cdietrich
Copy link
Member

cdietrich commented Apr 5, 2020

Can you reproduce this with 2.21 release?
Can you reproduce it in 2.22?

@miklossy
Copy link
Contributor Author

miklossy commented Apr 5, 2020

Not really. I saw that problem yesterday. Today I am working with the same environment for a while and have not seen that problem till now. It could be something that occurs sporadically.

@cdietrich Can you extract some information from the stracktrace that could help us further identify/reproduce the problem?

@miklossy
Copy link
Contributor Author

miklossy commented Apr 5, 2020

It could be something to do with the refactoring from Xtend to Java, so that the exception thrown in the try block became visible now through this code. The previous Xtend code contained a try-finally block without any catch clause, the java code however contains a try-catch-finally block.

@cdietrich
Copy link
Member

This is why I am asking. Was the exception catched and swallowed before?

@miklossy
Copy link
Contributor Author

miklossy commented Apr 5, 2020

Yes, that's the point, see my comments above.

@cdietrich
Copy link
Member

How was the old generated code?

@miklossy
Copy link
Contributor Author

miklossy commented Apr 5, 2020

You can find the old generated code here

@miklossy miklossy added this to the Release_2.22 milestone Apr 5, 2020
@cdietrich
Copy link
Member

@szarnekow any idea?

@cdietrich
Copy link
Member

So the old code had a different set of try and catch

@cdietrich
Copy link
Member

cdietrich commented Apr 5, 2020

@miklossy can you also check if thecalling code was migrated (HighlightingReconciler)

@miklossy
Copy link
Contributor Author

miklossy commented Apr 5, 2020

So the old code had a different set of try and catch

Exactly.

@miklossy
Copy link
Contributor Author

miklossy commented Apr 5, 2020

@miklossy can you also check if thecalling code was migrated (HighlightingReconciler)

No. The HighlightingReconciler was originally implemented in Java.

@cdietrich
Copy link
Member

Would still help if this was somehow reproducible

@cdietrich
Copy link
Member

cdietrich commented Apr 5, 2020

public static <T> T throwUncheckedException(Throwable e) {
	if (e instanceof RuntimeException)
		throw (RuntimeException) e;
	if (e instanceof Error)
		throw (Error) e;
	if (e instanceof Exception)
		throw new WrappedException((Exception) e);
	throw new RuntimeException(e);
}

public final class OperationCanceledException extends RuntimeException {
...
Worker

@Override
	public void run() {
		setPriority(Thread.NORM_PRIORITY);
		try {
			while ((currentJob = pool.startJob(this)) != null) {
				IStatus result = Status.OK_STATUS;
				IProgressMonitor monitor = currentJob.getProgressMonitor();
				try {
					setName(getJobName());
					result = currentJob.run(monitor);
				} catch (OperationCanceledException e) {
					result = Status.CANCEL_STATUS;
				} catch (ThreadDeath e) {

=> before we rethrow. now we wrap
=> callers might see a different exception now

@cdietrich
Copy link
Member

=> elmininating sneaky throw complely might not be a so good idea
cc @tivervac @szarnekow

how shall be proceed. call the sneeky throw again?

@cdietrich cdietrich self-assigned this Apr 5, 2020
cdietrich added a commit to eclipse/xtext-core that referenced this issue Apr 5, 2020
…ehaviour)

Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de>
@cdietrich
Copy link
Member

we should also go through other PRs for that pattern

@miklossy
Copy link
Contributor Author

miklossy commented Apr 5, 2020

Would still help if this was somehow reproducible

I found something reproducible: If I execute the XtextGrammarQuickfixProviderTests test cases, I see the same exception in the console:

screencast


!STACK 0
java.lang.RuntimeException: org.eclipse.xtext.service.OperationCanceledError: org.eclipse.core.runtime.OperationCanceledException
	at org.eclipse.xtext.resource.OutdatedStateManager.exec(OutdatedStateManager.java:71)
	at org.eclipse.xtext.ui.editor.model.XtextDocument$XtextDocumentLocker.internalReadOnly(XtextDocument.java:525)
	at org.eclipse.xtext.ui.editor.model.XtextDocument$XtextDocumentLocker.readOnly(XtextDocument.java:497)
	at org.eclipse.xtext.ui.editor.model.XtextDocument.readOnly(XtextDocument.java:136)
	at org.eclipse.xtext.util.concurrent.IReadAccess.tryReadOnly(IReadAccess.java:50)
	at org.eclipse.xtext.ui.editor.validation.ValidationJob.createIssues(ValidationJob.java:87)
	at org.eclipse.xtext.ui.editor.validation.ValidationJob.run(ValidationJob.java:68)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: org.eclipse.xtext.service.OperationCanceledError: org.eclipse.core.runtime.OperationCanceledException
	at org.eclipse.xtext.service.OperationCanceledManager.asWrappingOperationCanceledException(OperationCanceledManager.java:72)
	at org.eclipse.xtext.service.OperationCanceledManager.throwOperationCanceledException(OperationCanceledManager.java:78)
	at org.eclipse.xtext.service.OperationCanceledManager.checkCanceled(OperationCanceledManager.java:87)
	at org.eclipse.xtext.linking.lazy.LazyLinkingResource.resolveLazyCrossReferences(LazyLinkingResource.java:142)
	at org.eclipse.xtext.EcoreUtil2.resolveLazyCrossReferences(EcoreUtil2.java:505)
	at org.eclipse.xtext.validation.ResourceValidatorImpl.resolveProxies(ResourceValidatorImpl.java:162)
	at org.eclipse.xtext.validation.ResourceValidatorImpl.validate(ResourceValidatorImpl.java:75)
	at org.eclipse.xtext.ui.editor.validation.ValidationJob$1.exec(ValidationJob.java:92)
	at org.eclipse.xtext.ui.editor.validation.ValidationJob$1.exec(ValidationJob.java:1)
	at org.eclipse.xtext.util.concurrent.CancelableUnitOfWork.exec(CancelableUnitOfWork.java:27)
	at org.eclipse.xtext.util.concurrent.WrappingCancelableUnitOfWork.exec(WrappingCancelableUnitOfWork.java:58)
	at org.eclipse.xtext.util.concurrent.CancelableUnitOfWork.exec(CancelableUnitOfWork.java:27)
	at org.eclipse.xtext.resource.OutdatedStateManager.exec(OutdatedStateManager.java:69)
	... 7 more
Caused by: org.eclipse.core.runtime.OperationCanceledException
	at org.eclipse.xtext.service.OperationCanceledManager.getPlatformSpecificOperationCanceledException(OperationCanceledManager.java:82)
	... 19 more

@cdietrich Do you see that also on your computer? Can you find that stacktrace somewhere in the Jenkins log?

@cdietrich
Copy link
Member

yes it get it

cdietrich added a commit to eclipse/xtext-core that referenced this issue Apr 5, 2020
…ehaviour)

Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de>
@cdietrich
Copy link
Member

@miklossy see the log files in the results

@cdietrich
Copy link
Member

(that seem to be not there for unknow reaons)

@cdietrich
Copy link
Member

cause

failure {
  archiveArtifacts artifacts: '**/target/work/data/.metadata/.log, **/hs_err_pid*.log'
}

@cdietrich
Copy link
Member

=> push a branch with a failing test and you will get all logs

@miklossy
Copy link
Contributor Author

miklossy commented Apr 5, 2020

The problem is that the XtextGrammarQuickfixProviderTest test cases still passes, although exception is thrown.

@cdietrich
Copy link
Member

test and arbritrary exceptions in log have nothing todo with each other in our setup

@szarnekow
Copy link
Contributor

=> elmininating sneaky throw complely might not be a so good idea
cc @tivervac @szarnekow

how shall be proceed. call the sneeky throw again?

I'd prefer a case-by-case decision.
Throwing checked exceptions without those being declared on the method signature does not allow a catch clause to be used for that specific exception.
Instead of sneakyThread, I'd prefer throwUnchecked which wraps only if necessary. We should even consider wrapping in a specific runtime exception similar to the idiom used for UncheckedExecutionException or RuntimeIOException.

cdietrich added a commit to eclipse/xtext-core that referenced this issue Apr 6, 2020
…ehaviour)

Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de>
cdietrich added a commit to eclipse/xtext-core that referenced this issue Apr 6, 2020
…ehaviour)

Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de>
cdietrich added a commit to eclipse/xtext-core that referenced this issue Apr 6, 2020
@cdietrich
Copy link
Member

Fixed in 2.22

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants