Bugzilla – Full Text Bug Listing
| Summary: | [Markers] Error description column in Problems is empty | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Nils Hammar <nils.hammar> | ||||
| Component: | Resources | Assignee: | John Arthorne <john.arthorne> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P2 | CC: | aditya, andrew.hayden, craigcw, Darin_Swanson, davis, ian, java97301, john.arthorne, jverhaeg, lars, n.a.edgar, pombredanne, rradutiu, skarzhevskyy, thomas.oellrich, Tod_Creasey | ||||
| Version: | 3.1 | Keywords: | helpwanted | ||||
| Target Milestone: | 3.2 M4 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Nils Hammar
Further analysis seems to indicate that this problem is related to available memory assigned to the JVM. I.e. shortage of memory may be the cause. Nils, what leads you to believe the problem is memory related? I've been seeing it in both M5 and now M6. In M6, I tried increasing the default memory to 384 MB in eclipse.ini, but it had no effect. My system has 768 MB of real memory. I've also tried with the following eclipse.ini settings recommended by eclipsepowered.org: -vmargs -XX:CompileThreshold=5 -XX:+UseParallelGC This is a pretty large annoyance which as one can't see what the errors and warnings are; just that they're present. Here's the list of plugins I'm currently using: # Subversion VCS plugin http://subclipse.tigris.org/update # Log4E: For configuring logging etc http://log4e.jayefem.de/update # Metrics: Code analyzer and dependency analysis From sourceforge; downloaded zip # Eclipse utils (editor position and refresh) From Sun site: https://eclipseutilplugins.dev.java.net/servlets/ProjectDocumentList # Python development toolkit http://pydev.sf.net/updates # SQL Explorer (from Squirrel SQL) From sourceforge: http://sourceforge.net/projects/eclipsesql # KeepResident: improves Eclipse interaction with Windows VM manager Download from site: http://suif.stanford.edu/pub/keepresident/ # Mevenide http://mevenide.codehaus.org/release/eclipse/update/site.xml I'm using Eclipse 3.1M6 now with Sun's JDK 1.5.0_02 on Windows XP SP2. Note: I've had a number of reports of similar behavior, but have not been able to reproduce yet. I suspect my difficulty in reproducing may be because this is a concurrency issue. If anyone can describe reproducable steps, it would really help with getting this resolved. I have the same problem running Eclipse 3.1M6 on WinXP SP2 with JDK 1.5.0_02-b09. After doing a full rebuild of all projects, the descriptions are back again. New errors/warnings are added correctly. After restarting Eclipse the description are gone. I had the same problems but after a clean and an immediat rebuild of the worspace (Project/Clean..), it's OK. Just upgraded to Eclipse 3.1 M7 this morning and I think this may be fixed. Initially the problem was there on startup, but a full clean and rebuild of the project brought the items back. During a few hours of use, I haven't been able to make error/warning descriptions vanish. I'll let you know if I can get this to break again in M7, but it looks good for now. Thanks! Please disregard my previous comment. After a restart of my machine this morning, when Eclipse 3.1M7 opened up, the descriptions were missing from the Problems tab again. Oh well, at least M7 seems more responsive overall than M6 which is a welcome improvement. As before a complete rebuild of the project brings them back, but on my system (2.6 GHz Pentium with 768 MB) a rebuild takes about 36 seconds so I don't want to do that every time I need to see a warning. I'm still able to reproduce this problem with Eclipse 3.1 final on WinXP running with JDK 1.5.0_03. I start Eclipse with the following shortcut: C:\java\eclipse\eclipse.exe -vm C:\java\jdk1.5.0_03\bin\javaw.exe -vmargs -Xms128M -Xmx512M It also happens on clean install of 3.1 on WinXP without changing the heap size. I still can't reproduce. I think that the problem is related to migrating from previous versions of eclipse. I upgraded from 3.0.2 to 3.1. When I solved and regenerated one of the warnings for which there was an empty description in the problems view - the description "suddenly" appeared. I'll specify the exact process: There was a warning that "The serializable class ServerBasicInfoMock does not declare a static final serialVersionUID field of type long". This description was empty in the problems view, so I could only workaround and see it while hovering the mouse over the warning icon inside the code editor. I quick fixed it and created a default serialVersionUID. I saved the file, so the warning disappeared from the problems view. I regenerated the warning - I removed the serialVersionUID field and saved the file again. The warning reappeared, of course, in the problem view, but now it appeared correctly - with the correct data in the description column. That led me to think perhaps the problem is related to some incremental compilation based on a byte code that was created in previous versions of eclipse. So I cleaned all the projects (project->clean...), and rebuilt the workspace. Voila! All of the description column got filled with the correct data. I'll try to create a test case - I'll create a workspace with a project with some warnings in 3.0.2 and try to open this workspace in 3.1. I hope this will be reproduced. BTW, I also looked with -consolelog startup option but in vain - no error is written there while displaying the problems view or at all. Amit. I haven't managed to reproduce this simptom exactly yet. However, I noticed some other problems with the display of the problems view when using 3.1 to open a workspace which was created and built in 3.0.2. The problems worsened when I changed the settings in the java-compiler at the 3.0.2. I hope this gives a further clue. I migrated project from 3.0.1 and had 1500 warnings during compilation. After I change one file switched to another file and back. Then selected full tree. all warnings descriptions disappeared except warnings in this file. Build Automatically cheeked. So I recreated workspace and project from scratch in 3.1. Got the same result. Then I changed Compiler->Errors/Warnings in options. Set all to ignore. Was unable to reproduce the problem. There was less warnings and all had descriptions no matter what! Then I clinked Restore Defaults in Compiler->Errors/Warnings. Now I'm able to work and Descriptions stays! But when Exit Eclipse and start again Descriptions disappear. When I close project and open it again Descriptions stays! My suspicions was that this is related to the System (Windows XP) Language I'm Using! I changed from Russian to English CA But I still had a problems... Tested using jdk 1.4.2_07 and 1.5.0_04. Got the same results. eclipse.exe -vm C:\jdk1.5.0\bin\javaw.exe -vmargs -ms256m -mx512m - XX:CompileThreshold=5 -XX:+UseParallelGC Was unable to reproduce the problem in small projects ~ 100 warnings. Hope this would help. *** Bug 88132 has been marked as a duplicate of this bug. *** *** Bug 100753 has been marked as a duplicate of this bug. *** We're experiencing this problem with Eclipse 3.1 as well (winXP SP2, hotspot VM 1.5.0_02-b09), and not just in the Description column of Problems, but also the Description column of Tasks. It's also noteworthy that we've had cases in which only some of the Descriptions went missing. In individual files the description of Tasks or Problems were always either all missing, or all correctly shown. With several open projects the lists showed a combination of such "description missing" / "description ok" files. We can confirm that recompiling a file fixes the issue with that particular file (so: cleaning everything also works, but it is unknown if/how the problem can resurface thereafter). Recompilation also seems the only way to fix it (changing filters or reopening doesn't show any effect on it). Still present in Eclipse: Version: 3.1.0 Build id: I20050627-1435 java version "1.5.0_04" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05) Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing) Well, What I recognized now in the behavior of the bug is that I had one file with one single warning present, and the text was visible. I then saved&compiled the file by pressing CTRL+S, and almost immediately the text message disappeared! After the compilation was done the warning disappeared to since I had fixed the warning. Hopefully this will give a better clue to where the offending bug is hiding! /Nils H. *** Bug 106255 has been marked as a duplicate of this bug. *** I have been hunting this down for a couple of weeks now and I don't have a consistently replicable case (I have never seen it). Does anyone have one they could post here? Sorry about the accidental re-assign You may want to post to the duplicate as well as the CC members are dropped when the bug is marked as a dup I wanted to let you all know that it is not Windows specific. I experience the bug with OS X 10.3 and 3.1 install. I've simply gone back to 3.0 for now. I see some common threads here (I hope). Is everyone who is getting this 1) Using a 3.0 workspace migrated to 3.1 2) Using a Sun 1.5 VM version 01 or 02? Is anyone getting this from a fresh workspace that was created in version 3.1 or later? I suspect we are not seeing it because we are not migrating our workspaces. I'm not using Sun 1.5 01/02 VM. I'm using a Sun 1.4.2 04 VM. Were you using a 3.0.x workspace? I have seen that in fresh workspaces as well, although with projects originally created in older versions. Still present running JDK 1.5.0_04 and _05. My experience is that the problem only occurs when having a workspace with many projects and a lot of errors/warnings in several projects. Please note also my earlier comment #17 on this issue. Another problem (that actually I'll investigate further before filing a bug report) is that ANT in Eclipse seems to behave different from a stand-alone ANT and that the build project name seems to be "misplaced" and replaced with the name of antother project. My gut feeling says that it *MAY* be related, but not necessarily. I was using a 3.0.x workspace...however we have seen this problem also occuring with a fresh 3.1 workspace. We do however have ~ 20 projects in the workspace, which is consitent with Nils Hammar's observations (https://bugs.eclipse.org/bugs/show_bug.cgi? id=83992#c25) I was able to reproduce this bug starting from a fresh workspace created with Eclipse 3.1.1. The problem seems to occur only after checking a larger project from CVS (3 projects in total), setting problem filtering "on any resorce in the same project" and switching between projects. Eclipse 3.1.1 Sun JDK 1.5.0_04 RHEL 4 Yes, I am using a workspace migrated from 3.0 to 3.1. JDK 1.4.2_02-b03, Windows 2000. Also, as with some of the other reporters here, I have several projects checked out from CVS, of which generally 3-4 are open at any given time and have interdependencies. We are not using CVS. Our projects are not setup with inter-dependecies. In build >20051003 I have improved the blank message issue. Currently it is
possible to get a blank string if the marker sent to the label provider is
either null or not of the correct type (our internal ConcreteMarker).
I suspect the issue is that the wrong type is being sent.
Marker is null is the message for null
{class.toString()} is not of a displayable type is the message for the wrong types
Currently I'm running I20051012-1200 and I have yet another time encountered the empty messages, so the modifications in Comment #30 did not give any extra information at all... *** Bug 107401 has been marked as a duplicate of this bug. *** *** Bug 110777 has been marked as a duplicate of this bug. *** As one user of eclipse-cs (Checkstyle Plugin) pointed out here http://sourceforge.net/tracker/index.php? func=detail&aid=1261926&group_id=80344&atid=55949 this may have something to do with persisting and restoring of the markers between sessions. *** Bug 66468 has been marked as a duplicate of this bug. *** *** Bug 46604 has been marked as a duplicate of this bug. *** *** Bug 115289 has been marked as a duplicate of this bug. *** I'm still able to reproduce this problem using the linux x86/GTK 2 version 3.1.1 of eclipse (Build id: M20050929-0840) with: java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) I have problem filters enabled to show problems on any resource of the same project. Limit visible items is switched off. One project contains more than 500 warnings (due to automatically generated code from jaxb). If needed, i could do some testing with the projects i have here. In which plugin projects is the problems view populated? Problems view is in the IDE plug-in. Is it possible in your work environment to work with 3.2 M3 for a while? I have put in some code that should help us indicate the culprit in M3. (In reply to comment #39) > Problems view is in the IDE plug-in. Is it possible in your work environment to > work with 3.2 M3 for a while? I have put in some code that should help us > indicate the culprit in M3. I'm running M3 for the moment and the problem is still present, and the fields are still blank. As I understood it the fields were supposed to be populated with special data when certain conditions were met. This hasn't happened for me yet. Are these markers generated by the javatooling? I suspect someone is creating markers with no description. (In reply to comment #41) > Are these markers generated by the javatooling? I suspect someone is creating > markers with no description. They are definitely indicating Java errors/warnings, since double-clicking them brings up the offending line in the source. If there is more than one culprit behind writing the messages is beyond me. Anyway, the observation I made in Comment #17 may have some bearing on the issue. Are the message texts stored in a Hashtable/Vector that is cleared under some conditions? > Are these markers generated by the javatooling? I suspect someone is creating
> markers with no description.
As I interprete the myriads of similar bug reports this affects a variety of
different marker types including java markers and checkstyle markers (from eclipse-cs plugin).
As for the checkstyle markers I can guarantee that a description is always set.
In fact the problem reports mention that after a full rebuild all markers are in correct shape - at some point afterwards the marker description seems to vanish from the problems view - without the markers actually being changed.
There is a cache object to prevent having to hit the filesystem so much yes (the ConcreteMarker) but we only refresh from the marker rather than clearing it. (In reply to comment #40) > (In reply to comment #39) > > Problems view is in the IDE plug-in. Is it possible in your work environment to > > work with 3.2 M3 for a while? I have put in some code that should help us > > indicate the culprit in M3. > > I'm running M3 for the moment and the problem is still present, and the fields > are still blank. As I understood it the fields were supposed to be populated > with special data when certain conditions were met. This hasn't happened for me > yet. > I also can confirm that the field are still blank after restarting with m3. After a full rebuild the description is shown. But this is not an very usable workaround when having several large projects open in the workspace. I am using latest M3 milestone "Version: 3.2.0 Build id: I20051102-1600" and am still vahing major grief from this problem. I have a 2 completely new workspaces one with a single large project another with 10 smaller projects but all up 200 source files.
I cannot get the problem and task descriptions to disappear predictably but by updating and saving a single compitalion unit its marker's descriptions will show in the problem and task views.
Looking through the eclipse source it seems likly to me that ConcreteMarker is caching the description before the underlying marker has generated it. I am not in a position to recompile eclipse itself, but suggest changing the getDescription method in ConcreteMarker to use the underlying property e.g.
/* (non-Javadoc)
* @see org.eclipse.ui.views.markers.internal.MarkerNode#getDescription()
*/
public String getDescription() {
return Util.getProperty(IMarker.MESSAGE, marker);
}
This may reveal the root cause of the problem. Then again I may be looking in completely the wrong place. I would be more than happy to test a patch if someone can build it for me.
Re my last comment. should read "2000 source files" Thanks for your input Trevor - I thought the same thing so on 1122 I changed FieldMessage (the one that generates the description) to be
if(node.isConcrete()){
//Refresh as there is a still unknown empty description issue
if(node.getDescription().length() == 0)
((ConcreteMarker) node).refresh();
return node.getDescription();
}
Your theory sounds really plausable though - I'll check into that as well. If you patch Field Message in your plug-in with the one from HEAD (or run with an I build starting on the 29th) you will get this.
I've done some debugging and found out that sometimes, attributes like the message of markers aren't saved to disk. The cause is that the code 'if (elements[i] == key)' returns false for some reason when getting the value of the attribute. After changing the code and a full rebuild the problem description don't disappear anymore (at least here).
I've only checked this with 3.1.1 on WinXP. I'll check later with the same Eclipse version on Linux.
Here are the changes i've done:
Index: MarkerAttributeMap.java
===================================================================
RCS file: /cvsroot/eclipse/org.eclipse.core.resources/src/org/eclipse/core/internal/resources/MarkerAttributeMap.java,v
retrieving revision 1.12
diff -u -r1.12 MarkerAttributeMap.java
--- MarkerAttributeMap.java 21 Feb 2005 23:10:23 -0000 1.12
+++ MarkerAttributeMap.java 25 Nov 2005 11:52:16 -0000
@@ -69,7 +69,7 @@
if (elements == null || count == 0)
return false;
for (int i = 0; i < elements.length; i = i + 2)
- if (elements[i] == key)
+ if (elements[i] != null && elements[i].equals(key))
return true;
return false;
}
@@ -127,7 +127,7 @@
if (elements == null || count == 0)
return null;
for (int i = 0; i < elements.length; i = i + 2)
- if (elements[i] == key)
+ if (elements[i] != null && elements[i].equals(key))
return elements[i + 1];
return null;
}
@@ -200,7 +200,7 @@
// replace existing value if it exists
for (int i = 0; i < elements.length; i = i + 2) {
- if (elements[i] == key) {
+ if (elements[i] != null && elements[i].equals(key)) {
Object oldValue = elements[i + 1];
elements[i + 1] = value;
return oldValue;
@@ -241,7 +241,7 @@
if (elements == null || count == 0)
return null;
for (int i = 0; i < elements.length; i = i + 2) {
- if (elements[i] == key) {
+ if (elements[i] != null && elements[i].equals(key)) {
elements[i] = null;
Object result = elements[i + 1];
elements[i + 1] = null;
Thanks very much for your help with this Jörg - I am adding John to the cc list as if this is an issue in the core resources we will need this fix applied. If anyone else wants to test my changes with eclipse 3.1.x i've uploaded the core.resources plugin to http://finalize.de/org.eclipse.core.resources_3.1.0.jar Investigating... Jorg, it looks like you have narrowed down the cause, but I don't think your patch is the proper fix. The marker attribute keys are interned, so comparison with equality shouldn't be necessary. This is an important optimization in both speed and space for marker attributes. If your patch fixes the problem, it suggests that non-interned keys are leaking into the map. Can you (and anyone else seeing this problem), try this patch instead: http://eclipse.org/eclipse/platform-core/downloads/patches/bug83992/org.eclipse.core.resources_3.1.2.jar Simply drop this JAR into the plugins directory of a 3.1.x release, and restart with the -clean command line argument. John, it looks like that you change fixes the problem. Great work - this problem was really annoying. Could you send me a diff of the changes you've done for this? I'm interested to see how it was finally fixed. Regards, Jörg Created attachment 30722 [details]
Source patch for fix.
We have a background "string sharing" job that searches for strings in all the workspace model in memory, and replaces any duplicate equal strings with unique values (this does NOT use the String.intern() method). The problem was that this string sharing was replacing an interned key with some canonical non-interned but equal string. Subsequent lookups using identity on the interned value would then not match. The failure case can be very subtle - to reproduce I created a resource in my workspace called "message", created a marker, and then forced the string sharing job to run. Subsequent lookups of the marker attribute with key "message" would then fail because the key has been replaced with the string taken from the resource name. This explains why only some people have noticed it and others could never reproduce, and why it only appeared on certain marker attributes. They must have had a resource or a session property on a resource with the same name as one of the marker keys (such as "message" in the case of problem descriptions). Thanks are due to Jorg for getting us 99% of the way with that patch. I will release the fix to both 3.1.2 and 3.2 development streams. If others experiencing the problem can validate with the patch in comment #53 that would be great - just to make sure that everyone has been experiencing the same problem. Fix released to 3.1.x and 3.2 streams. Tomorrow's 3.2 integration build and Wednesday's 3.1.2 integration build will contain the fix for those who want to verify. Well done John!!!! I've been testing the latest Integration build for the last few days and not seen any sign of this most persistent little bug. |