Community
Participate
Working Groups
Build Identifier: M20100909-0800 Copied from comment #24 to bug 294959: > Please see the screenshot depicting a bunch of outdated markers in the Problems > view. At the time the screenshot was captured the build had finished > successfully way ago. Clean build or manual marker deletion did not help to get > rid of these. Only restarting the workbench helped. > > Can repeatedly reproduce the problem, but unfortunately the setup is quite > involved and can't be of much help here - JavaBuilder (including APT) + > XtextBuilder + custom Xtext extensions + custom Xtext languages (including Java > code generators). Build id: M20100909-0800, if it matters. I suspect it may > affect later versions also, but have not tried it - unfortunately it's not so > simple due to the aforementioned complex setup. > > Couldn't reproduce the problem when stepping through code with debugger, seems > to be a concurrency-related issue. No much help, sorry. Reproducible: Always
Created attachment 207769 [details] Screenshot
I think I can try to give a bit more details and attach some more screenshots to illustrate the problem a little further. Those strange-looking markers on the screenshot attached seem to really be Java problem markers, somehow outdated. They were originally the result of workspace (auto-)build, caused by a change in the '.classpath' file. The builders configured on the project are JavaBuilder and XtextBuilder, in that order. Both APT and XtextBuilder are configured to generate code to 'src-gen' source folder. Due to a bug, the classes _A, _B and _C were not (re-)generated by XtextBuilder after classpath change. Since those classes are extended by (manually-written) classes A, B and C, there are Java compilation problems depicted on 'screenshot1' (soon to be attached). Next, I tried a clean build, and strangely enough, the result seems to depend on if the Errors list is collapsed or not in the Problems view. If it was not collapsed before the clean build, I get the result depicted on 'screnshot2' (soon to be attached). As can be seen, the original Java problem markers seem to be in place and Package Explorer displays corresponding error ticks, but if we try to examine the properties of those error markers, they will be empty. It should be noted that the clean build had actually completed successfully, so no problem markers were expected. But if the Errors list was collapsed before the clean build, we get the result depicted on 'screenshot3' (soon to be attached). It is the same as the original screenshot, but additionally shows that those strange-looking markers also have no properties. I can add, that when breakpoints are installed at the #build methods of JavaBuilder and XtextBuilder and I slowly step through, I see that the Problems view is cleaned with a noticeable delay after the error ticks are cleared out in the Package Explorer after the JavaBuilder successful completion in the second iteration of the (clean build) loop. No outdated markers in this case. I hope this will clarify things a bit.
Created attachment 207772 [details] Screenshot1
Created attachment 207773 [details] Screenshot2
Created attachment 207775 [details] Screenshot3
Created attachment 207780 [details] Screenshot1a Replaced 'screenshot1' with a new one which additionally shows marker properties.
(In reply to comment #2) > The builders > configured on the project are JavaBuilder and XtextBuilder, in that order. Shouldn't XtextBuilder run before the JavaBuilder? As XtextBuilder's output is clearly required for JavaBuilder. > Both > APT and XtextBuilder are configured to generate code to 'src-gen' source > folder. Due to a bug, the classes _A, _B and _C were not (re-)generated by > XtextBuilder after classpath change. Since those classes are extended by > (manually-written) classes A, B and C, there are Java compilation problems > depicted on 'screenshot1' (soon to be attached).
(In reply to comment #7) > Shouldn't XtextBuilder run before the JavaBuilder? As XtextBuilder's output is > clearly required for JavaBuilder. No, it should not. When XtextBuilder generates some code, it triggers 'needRebuild', so JavaBuilder can see it in the same build loop (second iteration). Placed otherwise, XtextBuilder could not see the code generated by APT, for example. I should also note that such a placement is not a 'custom trick', but Xtext's default. The bug mentioned (absence of the generated classes after classpath change) is actually a consequence of bug 365160, please see it if you are interested in details. As a side note, I do not believe that this problem is related to builders as such, and has nothing to do with APT for sure (as I said APT was configured to generate code in 'src-gen', but there was no actual annotation processing in this case). My intuition is that it is the Problems view infrastructure (which undergone quite serious modifications in 3.6 related to concurrency) that has a race leading to displaying 'stale' markers. That's why I originally posted it as a comment to bug 294959. Of course, I may be wrong, since I couldn't track it down under debugger, but based on the observed behavior it's quite the only meaningful explanation I can see.
It seems I can reproduce the problem in a much simpler setup. Steps to reproduce: Prerequisite. You should have Xtext 2.1.x installed in your workbench and in your target platform. 1. Import the soon-to-be-attached 'org.example.mydsl' and 'org.example.mydsl.ui' projects in your workspace. 2. Launch the runtime workbench and import the soon-to-be-attached 'hello' project into the runtime workspace. 3. Make a clean build and restart the runtime workbench. 4. Make a change to the 'hello' project classpath. I just open the '.classpath' file and swap 'dummy.jar' and 'JavaSE-1.6' entries around. It seems that 'src' and 'src-gen' entries could be swapped around for the same effect. 5. Now you should have 3 errors in the Problems view. Make sure the Errors list is collapsed and make a clean build. Note that the error markers are still in place in the Problems view and they are now strange-looking (like those on the original screenshot). Note: strangely enough, it seems important for reproducing the problem that the (auto-)build after classpath change should be the first build in the session.
Created attachment 207783 [details] MyDsl language projects
Created attachment 207784 [details] Hello test project
Clarification: step #3 should really be 'Make a clean build of the runtime workspace and restart the runtime workbench.' Sorry for the ambiguity.
> Note: strangely enough, it seems important for reproducing the problem that the > (auto-)build after classpath change should be the first build in the session. As a side note, it may be caused by the blindspot mentioned in bug 365160 which is necessary to certainly get the error markers in the first place (the following builds are subject to generally unpredictable ordering of XtextBuilder scheduled by ProjectClasspathChangeListener and workspace auto-build, as mentioned in the bug). Also, the first build in the session is taking noticeably longer (Xtext activation?) which may have concurrency-related effects.
Please excuse me, but I still believe the issue belongs more to the Problems view (Plaform UI), than to Xtext. The Xtext bug mentioned only causes the (valid) Java problem markers to appear in the first place. It has nothing to do with 'stale' (invalid) problem markers. This bug was originally placed against Platform Resources as suggested by John Arthorne and I hoped it would stay there until further investigation.
(In reply to comment #14) > This bug was originally placed against > Platform Resources as suggested by John Arthorne and I hoped it would stay > there until further investigation. Sure, feel free to move it to Platform Resources again. (Though they moved it to JDT and at this point I don't see how this is a bug in JDT)
(In reply to comment #15) > Sure, feel free to move it to Platform Resources again. (Though they moved it > to JDT and at this point I don't see how this is a bug in JDT) Honestly, at this point I also don't think that this bug should belong to JDT (see comment #8). Neither Xtext. It's funny, but I can't move it to Platform Resources (when I select Platform as a Product, only TMF Components are available). Can you help me please?
(In reply to comment #16) > Honestly, at this point I also don't think that this bug should belong to JDT > (see comment #8). Neither Xtext. It's funny, but I can't move it to Platform > Resources (when I select Platform as a Product, only TMF Components are > available). Can you help me please? Once you select a product, a new page loads where you can select the component. I know it is quite confusing..
(In reply to comment #17) > Once you select a product, a new page loads where you can select the component. > I know it is quite confusing.. The problem is once I select a product, no new page loads. Perhaps I've got a wrong browser (Safari) or maybe it's a bugzilla bug :-) Thank you for your help, Deepak!
Moving to UI. See comment 8 and comment 14.
Created attachment 207849 [details] Screen shot Thank you for providing the detailed steps to reproduce, Vladimir. I am trying your steps but I see compile errors in your sample DSL project. See the screen shot.
(In reply to comment #9) > It seems I can reproduce the problem in a much simpler setup. > > Steps to reproduce: I tried these exact steps with a recent Eclipse 3.8 build and couldn't reproduce the problem. I'm hopeful this means it is an old bug that has since been fixed. If you like, we have some introspection tools that would help verify whether it is a problem with the markers themselves or the view. I will attach a zip containing three projects. Import those into your workspace before launching your runtime workspace. Then open the view called "Marker View" in the "Resources Tools" category. Click on any resource in the package explorer to see what markers it has on it at any given moment. There is a toggle in the view to change the "depth" to see all markers on a resource and its children. This view doesn't do any kind of refreshing or updating - it just tells you what markers are present at the moment you selected the resource. If the marker is missing from this view but still shows up in the Problems view, it's definitely a refresh bug in the Problems view.
Created attachment 207857 [details] Spy tools projects in zip
Created attachment 207858 [details] MyDsl language projects (updated) John, it's supposed to be french quotation marks (guillemets) which Xtext uses for rich string designation. Unfortunately, I forgot to explicitly set project encoding (my workspace default is "UTF-8"), so it's basically encoding issue. Please use the updated version I've attached which has project encoding explicitly set to "UTF-8". My apologies for the inconvenience.
John, thanks a lot for sharing these tools. I'm already at home now and unfortunately don't have the exact setup to try it right now, but today I've conducted a similar experiment at work. I've implemented a simple 'marker tracer' (based on #findMarkers API) and with some AspectJ magic, I've been able to take marker snapshots on each exit from JavaBuilder#build method. From that, it can be shown that it's a refresh bug in the Problems view. Unfortunately, I can't share the exact results (including traces and screenshots) till Monday, but in a few words, the (clean) build loop proceeds in two iterations. After the first iteration, JavaBuilder creates exactly the same error markers that will be shown later as 'strange-looking' in the Problems view (same identities). But after the second iteration, those markers don't exist anymore. It's a refresh problem indeed.
(In reply to comment #24) > But after the second iteration, those markers > don't exist anymore. It's a refresh problem indeed. Thanks for the confirmation. If possible it would be interesting to try on a more recent stable build of Eclipse to see if it went away. At least I couldn't reproduce on a new build with your steps. Here is a link to most recent milestone: http://download.eclipse.org/eclipse/downloads/drops4/S-4.2M3-201110281100/index.php
Of course, I will try it and share the results. Thank you for your help, John!
(In reply to comment #25) > If possible it would be interesting to try on a > more recent stable build of Eclipse to see if it went away. John, I can reproduce the problem on 4.2M3 with the steps described. Please see the screen shot ('Screenshot4') and the annotated marker trace attached. I also noticed that in few cases, I couldn't get the (valid) error markers after performing step 4. In those cases I just restart the runtime workbench and repeat that step. The bug 365160 that causes those markers to appear after a classpath change (step 4) is concurrency-related, so in general it's a matter of timing - but the blindspot of Xtext's ProjectClasspathChangeListener should make it easy enough to reproduce (that's my theory, at least).
Created attachment 207895 [details] Screenshot4
Created attachment 207897 [details] Marker trace
Created attachment 207900 [details] Screenshot4 bis One more screen shot, confirming that there is no markers on 'A.java' after step 5.
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. If you have further information on the current state of the bug, please add it. 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. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
