Community
Participate
Working Groups
The Xtext AutoBuild / Incremental Build might run into an infinite loop under following conditions: (1) the Workspace Option "Refresh using native hooks or polling" is enabled in the Eclipse preferences (2) This makes PollingMonitor/RefreshManager/RefreshJob calling a workspaceoperation IResource.refreshLocal if a "outofsync" resource is found. (3) This will lead to a AutoBuildJob.interrupt() via org.eclipse.core.internal.events.BuildManager.interrupt() (4) This will lead to the Running XtextBuilder beeing canceled (the monitor watches the interrupt as well in XtextBuild.shouldCancelBuild) (5) Asume we have a Generator that generates lots of files on a incremental Build this will leed to (2) finding actual out of sync resources since IFile.setContents is not atomic (I will attach a small Generator that reproduces this) (6) since the build gets never finished it will start all over again
Created attachment 259250 [details] Sample Generator that reproduces the problem with some likelyhood
P.S: please note: debugging the PollingMonitor/RefreshManager/Job is tricky since it reschedules it self according to the time needed the last time. if you do not debug the monitor it runs every 8 seconds on my machine
As a workaround we subclassed XtextBuilder an switched of the AutoRefresh during the Xtext Build @Override protected IProject[] build(int kind, Map args, IProgressMonitor monitor) throws CoreException { ScopedPreferenceStore resourcesPluginPrefs = new ScopedPreferenceStore(InstanceScope.INSTANCE, ResourcesPlugin.PI_RESOURCES); boolean old = resourcesPluginPrefs.getBoolean(ResourcesPlugin.PREF_AUTO_REFRESH); resourcesPluginPrefs.setValue(ResourcesPlugin.PREF_AUTO_REFRESH, false); try{ return super.build(kind, args, monitor); } finally { resourcesPluginPrefs.setValue(ResourcesPlugin.PREF_AUTO_REFRESH, old); } }
I and several colleges have this bug and find working with xtext quite unnerving because of it. When will this get fixed?
i dont have a clue and no help .... so potentially never ....
imho this should be fixed inside the eclipse filesystem, the polling thingy ....
(In reply to Christian Dietrich from comment #6) > imho this should be fixed inside the eclipse filesystem, > the polling thingy .... Which way there? Any proposal?
i need someone that helps me understand the problem better and maybe create an example that reproduces the problem outside of xtext so that i can hand over the bug to platform ...
well i actually can reproduce this without xtext .....
Created attachment 268389 [details] Reproducing Non Xtext Builder
Created attachment 268390 [details] Sample Project
@Andrey Loskutov do you think it makes sense to file a platform bug?
another option would be to await all generation for one file before interrupting the xtext build but i am not sure if that would be a good idea
(In reply to Christian Dietrich from comment #12) > @Andrey Loskutov do you think it makes sense to file a platform bug? I haven't tried the example, but if the infinite build happens with that example too, please simply move this bug to platform resources.
well the point is i am not sure if the forgetLastBuildState is legit or not
(In reply to Christian Dietrich from comment #15) > well the point is i am not sure if the > > forgetLastBuildState is legit or not So the question here is if the code pattern below is legit: build(){ ... if (isInterrupted()) { forgetLastBuiltState(); } } This looks like this is a problem of the (non-incremental) builder, but on the other side, BuildManager also triggers forgetLastBuiltState() in org.eclipse.core.internal.events.BuildManager.getSafeRunnable(...).new ISafeRunnable() {...}.handleException(Throwable). Question: can you modify the example to get this build manager code path involved? For me it looks like a platform bug. I just wonder how this could be addressed?
well xtext maintains internally what was build and what was not so it will rebuild the current resource and the onces not build yet.
@andrey i dont get your point protected void forgetLastBuiltState() { oldState = null; forgetStateRequested = true; rememberStateRequested = false; } this is what xtext/my builde calls. the build manager then picks it up
git it. changing the code to if (isInterrupted()) { throw new OperationCanceledException("i was Interrupted"); } does that. behaviour stays the same
Moved to the platform, patch is welcome.
I get an endless loop after updating xtext project resources externally, even though I have "refresh on access" rather than "refresh using native hooks or polling". Do you think the reason for my bug could still be same as for the bug described here, or should I file a seperate bug?
it can be this issue but others as well. (e.g. subclipse) you should debug -if autobuild is cancelled -if xtext build is interruped by this cancelaction or another reason org.eclipse.xtext.builder.impl.XtextBuilder.handleCanceled(Throwable) org.eclipse.core.resources.IncrementalProjectBuilder.forgetLastBuiltState() org.eclipse.core.internal.events.AutoBuildJob.setInterrupted(boolean)
(In reply to Andrey Loskutov from comment #16) > For me it looks like a platform bug. I just wonder how this could be > addressed? From my observations there seems to be a fundamental problem witrh the platform. It should be possible for e.g. a) GIT to declare a multi-project change starting b) GIT to do multiple project changes without any auto-build happening for the multi-projects c) GIT to declare the multi-project change complete after computing a rebuild all/incremental recommendation to the auto-builder d) platform to start all/incremental build IMHO so long as incremental builds start every time an individual project file changes, the performance of a GIT commit change is guaranteed to be SH*T.
I've been hitting occasional test failures on Travis in tycho-surefire tests that involve auto-build that sound just like this problem [1]. This is with Java-based WTP projects: no XText involved. One of my team members suspects that some occasional test failures involving WTP XML validation may be related: in this case, expected validation errors aren't being marked, implying that the validation is either interrupted or somehow ended prematurely. We've noticed that this happens almost exclusively on Neon and Oxygen. We rarely see problems on Mars. Debugging this 'remotely' is a pain. I need to figure out create a feature patch for org.eclipse.core.jobs to introduce some instrumentation. [1] https://github.com/GoogleCloudPlatform/google-cloud-eclipse/pull/1529#issuecomment-287403084 [2] https://github.com/GoogleCloudPlatform/google-cloud-eclipse/issues/2076
There are other places that cancel the build as well e.g. https://bugs.eclipse.org/bugs/show_bug.cgi?id=519776
I've been running my failing test case with Rastislav Wagner's patch for bug 478634 (https://git.eclipse.org/r/56954) and haven't had any failures. Could others see if it helps with their test cases?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Any update on this topic? I have also encountered this problem recently on a customer project. The problem still exists (occurs occasionally) with Eclipse 2020-12 and Xtext 2.24.
for subclipse please check https://github.com/subclipse/subclipse/issues/48
