Community
Participate
Working Groups
Sometimes after a restart of eclipse/ clean build, Jars in added libraries are not recognised and this results in compilation error. To solve the problem, I have to remove the library assignment to the project, build the project and add the project again. Occurs in Win2k and WinXP
Please provide reproducable test case and attach the library to this bug report. Also provide contents of the .log file in the .metadata folder. Thanks. Reopen when requested information is available.
This bug bites many people, incl. us. You may Google for "unbound classpath container" or similiar, e.g. http://dev.eclipse.org/newslists/news.eclipse.tools.jdt/msg16305.html and you will see that this bug exists since a while and still persists. It seems to almost always emerge in real-world size projects while not being reproducible easily in toy projects. Our workspace is 150MB and cannot be attached, contains 7 dependent projects incl. WST and we almost stopped using Eclipse because of this. No other IDE (IntelliJ, NetBeans, JB) ever had problems with this workspoce and our user libraries. Most of the time (70%), one of the projects does not build because of unresolved imports (this bug). Sometimes (10%), a user library all of a sudden is flagged "unbound classpath container". Only 20% of time a build will succeed. Needless to say that other Builders continue to build AFTER a Java Builder failed (but this is another bug of normal severity). We got the idea that this may be related to packages appearing multiple times on the classpath (which is quite normal). We also observed that Eclipse does not notice until restart when a library changes on disk (other IDEs do -- is this normal for Eclipse or could it be part of the problem?). Please, can somebody take care of this or announce that bugs of this kind will not receive attention? Thank You. Eclipse Version: 3.2.1 Build id: M20060921-0945 Win XP JDK1.5.
I will make a few attempts of my own to reproduce the behavior you describe, but the elements asked by Olivier would help us to narrow down the issue. Another question of interest: did you try 3.2.2 or any milestone of 3.3 and, if yes, which outcomes did you get?
*** Bug 175183 has been marked as a duplicate of this bug. ***
I have recently found one more problem. Please feel free to open a new one if these two do not fall under same category. Our setup is like this: We have a team of 15 developers. All our Java sources are in Clearcase as different projects. We have the project definitions stored in Clearcase. I.e. we have a separate directory in clearcase for each project which will have .project and .classpath files. All of us use different workspaces (in Hard disk). We will load these projects into the workspace using 'create project from existing workspace' and refer to clearcase path. In our workspace preferences, we have linked resources for a variable pointing to a base location for all the project sources (in clearcase). In the .project we add the linked resources using this linked variable. Now the problem is: - If for some reason (e.g. config spec is wrong) we could not see the project sources once. - Eclipse will not show these files (as they do not exist in the path specified) - After this instance, every time we load eclipse with the same projects, we cannot see the sources in the project explorer even if it is made available (e.g. config spec corrected). - We have to delete the project from workspace(do not delete content) - And add it again by creating a new project from existing source. Let me know if you feel the way I am doing is not ok.
Think we have the same problem here. (BTW: The Problem described by Sammpath is a different one I think) This one is annoying. We use UserLibraries, since our PackageExplorer Tree would simply be too large if we'd import the libraries one for one. So we've choosen to use UserLibraries (even if they are shared with every teammember). But now, this Bug bites us every few days (I can not say what causes it, sometimes it works , sometimes not). Sometimes, a restart of eclipse helps, sometimes not. rebuilding, readding of the library does not work. I have to say, that our project is a large one too, but no problem with other IDE's... We use 3.2.2 . While I think it occured in 3.2.1 already, I am sure it appears a lot more since we use 3.2.2 . But I have to say, that we added some new libraries since too... This Bug is NOT resolved.
We're seeing the same problem here. Sometimes, a workspace can remain unaffected by the problem for long periods of time, sometimes it happens almost daily.
(In reply to comment #6) ... > This Bug is NOT resolved. REMIND means: we would like to get more information to investigate. As announced above, I'll spend some time to try reproduce the problem on my side. But the information provided so far does not constitute a test case that would be predictable and reasobably practical. That is the reason of the bug status.
Sorry then for this, but the help page of the "Resolution" does not mention what "Remind" means. Unfortunately, this is not reproducable always. It really occurs only on one of our projects (the biggest one of corse), but never on the toy-projects. Where can I find the Eclipse Logfile?
(In reply to comment #5) This is not related to this bug. From the tests I have made with I20070222-0951, extending a path variable to create a linked folder resolves the variable before storing the resulting path. (Look at .project contents: you will have a linkedResources entry with a location set to an absolute path that matches the filesystem of the developer who created the linked resource), and changing the path variable value afterwards does not change the linked resource location (as displayed in the properties context menu - aka c:\tmp\somedir). If I am right in my reading of the help topic on path variables, this is not the intended behavior. I encourage you to open a separate bug against Eclipse/Platform/Resources to get this investigated. (For the records, I did my tests with java projects only, extending the variable or using it as is, the variable referencing a source folder of an existing project within another workspace, the other workspace being open within another eclipse instance, or closed.)
By default, the log is a .log file in the .metadata directory of your workspace.
Inviting Jérôme in the conversation since this might be related to race conditions in the Java model.
(In reply to comment #9) > Sorry then for this, but the help page of the "Resolution" does not mention > what "Remind" means. Opened bug 177497 against the Eclipse web site.
I do not agree that this bug carries the state "RESOLVED" (even if the resolution is "REMIND"). It should either be kept open or be closed wontfix or cantreproduce. This is why I created a new bug in the first place, which now was closed "DUPLICATE". This bug is shown as "RESOLVED" in all lists (dashed out) while in reality, there is an OPEN bug which renders Eclipse UNUSABLE for many of us professional programmers. Also, people being hit by this will normally only search in the list of UNRESOLVED issues to find out if others have similiar problems. In summary: I would like to change state to "OPEN" by the user interface does not give me this option...
(In reply to comment #3) > Another question of interest: did you try 3.2.2 or any milestone of 3.3 and, if > yes, which outcomes did you get? Maxime: I had and have this problem with 3.2.2. 3.3 is, I think not marked as production quality. I will attach the log files. But there is an awful lot of stuff in it which I will not be able to parse manually :-( Another observation: I did a number of changes in my setup which made this problem occur less often: (1) I moved user libraries from our repository (a network share) to a local copy (2) I rearranged some jars so that packages appearing in multiple jars are less numerous. (3) I try to avoid running Builders other than Java (i.e. Ant scripts with "refresh after run" option). Still, the problem is still there! My last observation: (HERE COMES A POSSIBLE HINT WHERE THE PROBLEM MAY EMERGE FROM:) In one of my projects (in the workspace) which stopped building, the corresponding user library did NOT contain any JARs any more (what you see by opening the little triangle next to it). It should have displayed 3 JARs. In the user library listing, when opening the triangle, I see all 3 JARs. Obviously, there are DIFFERENT descriptors for the same user library within Eclipse which can become out of sync. Hard to believe, I know... And then: It does NOT help to drop and add the user library within the project. I had to drop the user library, recompile (with errors, of course), close and RESTART Eclipse, add the user library again and then (now successfulyl) recompile. Obviously, there can be a broken stealth descriptors for a user library within Eclipse which is hard to get rid off (a simple restart -clean does NOT help!). Maybe this observation gets you up and running. I fear there cant be a test case for this bug. However, a simple code review should reveal it as well.
Created attachment 60918 [details] Logfile of Eclipse workspace (part #1)
Created attachment 60919 [details] Logfile of Eclipse workspace (part #2)
Thanks for the additional information. Definitely looks like a consistency problem at the user libraries level. Jérôme, do you want me to investigate, or will you take over? BTW, many of the log entries complain about file deletion problems (eg C:\home\falk\dev\ercatoEngine\xoperator\tasks\xop.jar\tmp.jar). Do those files have specific properties? Are they still present on your disk?
We would need more information about the container initialization. Maxime, please explain to Falk how to get the trace so that Falk can attach it to the bug.
Created attachment 60934 [details] JDT options to debug classpath related activities Falk, Please drop the attached file in your Eclipse 3.2.2 eclipse directory. From a DOS prompt, navigate to your Eclipse 3.2.2 eclipse directory and execute the following command: java -jar startup.jar -debug eclipse_jdt_options.txt > jdt.log Expect the log file to grow fairly rapidly. It would help us that you stop the session as soon as you hit the issues and that you give us the names of some of the missing jars so as to ease the log interpretation. Thanks in advance.
(In reply to comment #18) > BTW, many of the log entries complain about file deletion problems (eg > C:\home\falk\dev\ercatoEngine\xoperator\tasks\xop.jar\tmp.jar). Do those files > have specific properties? Are they still present on your disk? Maxime: The file deletion problems seem to be unrelated. I create JARs in ant scripts using jar, fatjar and autojar. Some of those commands seem to keep a JAR locked so that I cannot delete it at the end of a ant task. However, I can delete it after the ant task so this no big concern for us. Of course, we would prefer Eclipse to have a single build-in Builder covering the functionality of jar, fatjar and autojar, very much like JBuilder had since 1998...
(In reply to comment #21) > (In reply to comment #18) > > BTW, many of the log entries complain about file deletion problems (eg > > C:\home\falk\dev\ercatoEngine\xoperator\tasks\xop.jar\tmp.jar). Do those files > > have specific properties? Are they still present on your disk? > > Maxime: The file deletion problems seem to be unrelated. We suspected so. But we did not want to miss a potential bug if you had no good explanation for those log items. Thx for the clarification.
Created attachment 60943 [details] Debugging log (In reply to comment #20) > java -jar startup.jar -debug eclipse_jdt_options.txt > jdt.log I did as advised. My (formerly compiling workspace) immediately has missing JARs in user libraries in projects. The log file, however (attached) is almost empty. The exception seems to be related to Hyades; I believe this is a left-over from a former attempt to profile something (I profiled, then removed a profiling project generated by Eclipse during profiling from my workspace -- Eclipse must not create projects by itself). So, in summary: 2 out of 3 user libraries, in 1 out of 7 projects, in my workspace, all of a sudden lack their JARs. They are all there in the global list of user libraries. And I see no related Java exception in the log file.
Created attachment 60948 [details] debugging log after -clean (In reply to comment #23) I restarted Eclipse using the normal command and with -clean as well. In the case of -clean, a log-file entry in .metadata was created (attached) -- but again only a Hyades-relared exception. When I restart Eclipse and clean/rebuild everything, I get the problem with varying user libraries, i.e., the problem emerges somewhat at random with a given library, but when it appeared, it may heal with a low probability at the next restart/clean/rebuild, but with a high probability if I remove/add the user library to the project. One soon reaches the point where the workspace always fails to rebuild. It seems that a user-library only works with a probability of about 95% -- and if you have about 20 or so in your workspace, things start to get impossible...
(In reply to comment #23) > JARs in user libraries in projects. The log file, however (attached) is almost > empty. The exception seems to be related to Hyades; I believe this is a Falk, some java/os configurations do not perform as expected as far as stream redirection is concerned, and this seems to be the case with yours. As a workaround, would you please: - set you DOS window buffer size to 1000 columns per 9999 lines; - run eclipse as: java -jar startup.jar -debug eclipse_jdt_options.txt - copy-paste the console contents to a log file? Thanks again for your cooperation.
Created attachment 60952 [details] User library repository import file (In reply to comment #24) > It seems that a user-library only works with a probability of about 95% -- and > if you have about 20 or so in your workspace, things start to get impossible... Hi again. Because after the -debug session experiment, I cannot get my workspace back to compile at all :-( , I have some time to explain in more detail: One possible phenotype of the bug (there are others, as unbound classpath container etc. -- but I can describe this one best now) is as follows: (1) There is at least one user library entry in one project in the workspace, which ALL OF A SUDDEN has no JAR entries anymore if one opens the libraries' little triangle in the project's properties' dialog "Java Build Path", "Libraries" section. (2) At this time, the same user library exists in the global properties Java, user Libraries settings. Opening the libraries' little triangle in this dialog shows ALL JARs -- exactly as it should. (3) Removing, then adding this user library adds it to the project -- but always with all JAR entries REMOVED! So, adding/removing does not help! (4) Removing, then building, then restarting, then adding freqently helps, but not always. Restart and restart -clean do not seem to make a difference. (5) Sometimes, just restarting helps. BUT: Sometimes, a second restart (after the problem seemed to have gone) reproduces the old problem at the EXACT same library -- so somehow, there is a hidden cause which is sticky in a probabilistic manner. (6) Sometimes, a simple clean/rebuild helps as well. But only if one is desperate enough to do this over and over again because anything else fails anyway :-( (7) There are no related exceptions in any log file, and user libraries are (now) all local. However, I attach our user library repository file -- maybe you find something special here (it is a generated file).
Can you also attach the JDT/Core workspace preferences file 'org.eclipse.jdt.core.prefs' saved in .metadata\.plugins\org.eclipse.core.runtime\.settings directory of your workspace? It could be interesting to know when this problem occurs if the user library content is correctly saved in this preferences file... Thanks
(In reply to comment #25) > Falk, some java/os configurations do not perform as expected as far as stream > redirection is concerned, and this seems to be the case with yours. As a > workaround, would you please: > - set you DOS window buffer size to 1000 columns per 9999 lines; > - run eclipse as: > java -jar startup.jar -debug eclipse_jdt_options.txt > - copy-paste the console contents to a log file? > Thanks again for your cooperation. Maxime, you cannot believe the log is almost empty ;-) It is! (And btw, it DOES contain one exception trace) Of course, I catched both stdout AND stderr into the log file (your command line snippet would have missed stderr in ANY opertaing system...). There is no additional console output. My command line was as follows: $ java -jar startup.jar -debug debug_jdt_options.txt > debug_jdt.log 2>&1 using bash. Thanks for caring. So the question is: How can this go wrong WITHOUT exception in the log?
Falk, can I insist that you try without redirecting the stderr or stdout to any file ? It is impossible that you don't get any tracing with the content of the eclipse_jdt_options.txt file that Maxime provided you with.
Created attachment 60961 [details] org.eclipse.jdt.core.prefs (In reply to comment #27) > Can you also attach the JDT/Core workspace preferences file > 'org.eclipse.jdt.core.prefs' saved in > .metadata\.plugins\org.eclipse.core.runtime\.settings directory of your > workspace? > It could be interesting to know when this problem occurs if the user library > content is correctly saved in this preferences file... > Thanks See attachment. According to Windows, this file did not change since yesterday, and today, I had both, compiling and non-compiling, workspaces. So probably, this file is maybe not involved. Also, the global list of user libraries looks ok. It is the project-local list of libraries which gets broken by itself.
Created attachment 60963 [details] Debug output w/o error (In reply to comment #29) > Falk, can I insist that you try without redirecting Jerome, of course, you can insist. But this did not help. I cross-checked the debug-options file now and it has a download error (right click did not download what I saw on left-clieck :-( I did it again and now I get output (stderr+stdout). I attach 2 logfile: (1) Without error (opening the workspace shows no error). (2) With error (Opening and then clean/rebuild shows error). The affected user library is "Ercato Core API". It should have the following JARs: "ercapi1.jar", "esh.jar", "xop.jar" with various source and javadoc attachments. The affected project is "_ercatons".
Created attachment 60965 [details] Debug output w error in user library "Ercato Core API"
(In reply to comment #15) This is exactly the behaviour I have had (unfortunately, since I wrote about it, it did not happen again, so I can't post a logfile or screenshot of it) Markus > (HERE COMES A POSSIBLE HINT WHERE THE PROBLEM MAY EMERGE FROM:) > > In one of my projects (in the workspace) which stopped building, the > corresponding user library did NOT contain any JARs any more (what you see by > opening the little triangle next to it). It should have displayed 3 JARs. In > the user library listing, when opening the triangle, I see all 3 JARs. > Obviously, there are DIFFERENT descriptors for the same user library within > Eclipse which can become out of sync. Hard to believe, I know... And then: It > does NOT help to drop and add the user library within the project. I had to > drop the user library, recompile (with errors, of course), close and RESTART > Eclipse, add the user library again and then (now successfulyl) recompile. > > Obviously, there can be a broken stealth descriptors for a user library within > Eclipse which is hard to get rid off (a simple restart -clean does NOT help!). > > Maybe this observation gets you up and running. I fear there cant be a test > case for this bug. However, a simple code review should reveal it as well. >
(In reply to comment #28) > Maxime, you cannot believe the log is almost empty ;-) It is! (And btw, it DOES > contain one exception trace) Of course, I catched both stdout AND stderr into > the log file (your command line snippet would have missed stderr in ANY > opertaing system...). There is no additional console output. My command line > was as follows: > > $ java -jar startup.jar -debug debug_jdt_options.txt > debug_jdt.log 2>&1 > > using bash. Thanks for caring. So the question is: How can this go wrong > WITHOUT exception in the log? Mmm.... noticed the bug was opened against Windows, and didn't want to mandate the use of evolved shells... Anyway, I tested the procedure of comment #25 on an XP machine, and it worked (and you got it right to according to your comment #31). This kind of glitches sometimes creep in and poison our lifes ;-) Thanks for your persistence!
(In reply to comment #32) > Created an attachment (id=60965) [details] > Debug output w error in user library "Ercato Core API" > Thanks for the debug log. In what project the user library "Ercato Core API" is empty ?
(In reply to comment #35) > (In reply to comment #32) > > Created an attachment (id=60965) [details] [details] > > Debug output w error in user library "Ercato Core API" > > > Thanks for the debug log. In what project the user library "Ercato Core API" is > empty ? Hi, As I have said in comment #31: The affected project is "_ercatons". I had a look into the log myself. There is only 1 FAILED notice for this library and project, something like (but note that there are many more "<Fake exception>"): -- Thread[Worker-3,5,main] CPContainer INIT - triggering initialization Thread[Worker-3,5,main] project: _ercatons Thread[Worker-3,5,main] container path: org.eclipse.jdt.USER_LIBRARY/Ercato Core API Thread[Worker-3,5,main] initializer: org.eclipse.jdt.internal.core.UserLibraryClasspathContainerInitializer@14ad296 Thread[Worker-3,5,main] invocation stack trace: java.lang.Exception: <Fake exception> at org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer(JavaModelManager.java:1912) at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1267) at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:1470) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:2169) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:2073) at org.eclipse.jdt.core.JavaCore.setClasspathContainer(JavaCore.java:4189) at org.eclipse.jdt.internal.junit.buildpath.JUnitContainerInitializer.initialize(JUnitContainerInitializer.java:89) at org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer(JavaModelManager.java:1924) at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1267) at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:1470) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:2169) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:2073) at org.eclipse.jdt.core.JavaCore.setClasspathContainer(JavaCore.java:4189) at org.eclipse.jdt.internal.launching.JREContainerInitializer.initialize(JREContainerInitializer.java:57) at org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer(JavaModelManager.java:1924) at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1267) at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:1470) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:2169) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:2073) at org.eclipse.jdt.internal.core.search.JavaSearchScope.add(JavaSearchScope.java:107) at org.eclipse.jdt.internal.core.search.JavaWorkspaceScope.initialize(JavaWorkspaceScope.java:84) at org.eclipse.jdt.internal.core.search.JavaSearchScope.<init>(JavaSearchScope.java:61) at org.eclipse.jdt.internal.core.search.JavaSearchScope.<init>(JavaSearchScope.java:57) at org.eclipse.jdt.internal.core.search.JavaWorkspaceScope.<init>(JavaWorkspaceScope.java:29) at org.eclipse.jdt.internal.core.JavaModelManager.getWorkspaceScope(JavaModelManager.java:1729) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.createWorkspaceScope(BasicSearchEngine.java:155) at org.eclipse.jdt.core.search.SearchEngine.createWorkspaceScope(SearchEngine.java:397) at org.eclipse.jdt.internal.core.SourceType.newSupertypeHierarchy(SourceType.java:699) at org.eclipse.jdt.internal.core.SourceType.newSupertypeHierarchy(SourceType.java:652) at org.eclipse.jdt.internal.corext.util.SuperTypeHierarchyCache.getTypeHierarchy(SuperTypeHierarchyCache.java:120) at org.eclipse.jdt.internal.corext.util.SuperTypeHierarchyCache.getTypeHierarchy(SuperTypeHierarchyCache.java:80) at org.eclipse.jdt.internal.corext.util.SuperTypeHierarchyCache.getMethodOverrideTester(SuperTypeHierarchyCache.java:89) at org.eclipse.jdt.ui.OverrideIndicatorLabelDecorator.getOverrideIndicators(OverrideIndicatorLabelDecorator.java:162) at org.eclipse.jdt.ui.OverrideIndicatorLabelDecorator.computeAdornmentFlags(OverrideIndicatorLabelDecorator.java:129) at org.eclipse.jdt.ui.OverrideIndicatorLabelDecorator.decorate(OverrideIndicatorLabelDecorator.java:261) at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:259) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:71) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.runtime.Platform.run(Platform.java:843) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(LightweightDecoratorManager.java:336) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:322) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:338) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:308) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) Thread[Worker-3,5,main] CPContainer INIT - FAILED (initializer did not initialize container) Thread[Worker-3,5,main] project: _ercatons Thread[Worker-3,5,main] container path: org.eclipse.jdt.USER_LIBRARY/Ercato Core API Thread[Worker-3,5,main] initializer: org.eclipse.jdt.internal.core.UserLibraryClasspathContainerInitializer@14ad296 --
Created attachment 61063 [details] Expurged trace This is an extract of debug_jdt.log as provided in attachment 60965 [details]. Original line numbers are provided in column 1 so as to enable post-sync of most interesting parts.
Created attachment 61068 [details] screenshot shows library definition Shows the Library Definition while the library inside the Project(Package Explorer) is empty.
Created attachment 61069 [details] Screenshot of PackageExplorer with empty library Shows the Package Explorer with the empty library, while the UserLibrary in the Preferences is still ok (see 61068)
I was able to reproduce it partially today. Attaching two screenshots that show the problem appearing in the UI. The logfile does not contain anything of interest (lot of subclipse related exceptions). When starting up first today, the order of the libraries was: 1.TopEase 2.Tools 3.JRE System and it worked (no problems o far) Then I switched the order to: 1. JRE System 2. Tools 3. TopEase and the TopEase Library appeared empty after a restart of eclipse. After that I played around with the order of the libraries, but then it was always ok - it worked again, even with the configuration that did not work before (arrrrrgh)! I have to mention, that I switched of the "AutoBuild"-flag to be able to faster restart eclipse, maybe that was the reason that it worked afterwards. Markus
Created attachment 61070 [details] Focused log The attached focused log shows that the failure by Worker-3 to initialize 'Ercato Core API' while Worker-6 is busy initializing 'Livis Utils 1' prevents somehow Worker-6 to consider 'Ercato Core API' after it has finished its work with 'Livis Utils 1'.
The failure at index 770 is due to an exception in the initializer call at JavaModelManager#1924. This results into initializeContainer returning null and Worker-3 installing a default container at JavaModelManager#1290. Worker-6 will thereafter pick that one up instead of the real one. Jérôme, what do you think?
(In reply to comment #42) > The failure at index 770 is due to an exception in the initializer call at > JavaModelManager#1924. What is the exception ?
(In reply to comment #42) > The failure at index 770 is due to an exception in the initializer call at > JavaModelManager#1924. This results into initializeContainer returning null and > Worker-3 installing a default container at JavaModelManager#1290. Worker-6 will > thereafter pick that one up instead of the real one. > Jérôme, what do you think? Hi Jerome and Maxime, looks like you are making progress. Great! Also looks like the process of loading user libraries is not thread-safe. And of course: IF loading of user libraries is not thread-safe, how could this pass un-noticed by the tremendous mass of Eclipse users (all toy users?). Hope you can soon find the inner cause even, as should have become clear by now, there won't be a test case for this. -- BTW, question: why are there multiple workers involved at all? Does every project has one worker, or why else? And, proposal: Maybe, the processing of user libraries should be done by a singleton which then could also take care when JARs change on disk (which other IDEs do actually handle fine...). JARs may change outside of Eclipse (e.g., CVS update of a library repository) or may be changed by some builder within the workspace itself (in general).
(In reply to comment #43) > (In reply to comment #42) > > The failure at index 770 is due to an exception in the initializer call at > > JavaModelManager#1924. > What is the exception ? > Apologies. There is no exception here (else container would be null). The initializer call must return, merely leaving CONTAINER_INITIALIZATION_IN_PROGRESS in place. Then we return null, visiting the finally block before returning for real. The remainder of the analysis should stand.
OK. Then it looks like the container initialization support is not guilty here, but the UserLibraryClasspathContainerInitializer is. We should add tracing in this initializer (and its related classes) and provide a patch to Falk (and anyone interested in helping to debug this) to find out why the initializer fails to set the container value when asked for. Maxime can you please take care of that ?
Digging into the UserLibraryClasspathContainerInitializer, we have identify a potential race condition. Working on a fix. Will provide a patched jdt core plugin to users willing to help with in situ validation.
Created attachment 61253 [details] Suggested fix This patch, built against R3_2_maintenance stream and currently under test, remedies to the identified race condition by removing extra map allocations. Note that this cannot be the ultimate patch because UserLibraryManager#internalSetUserLibrary removes the change listener for a period of time, while it performs rebinding. Either the listener is not really needed, and that's fine (I mean, another mechanism takes care of signalling to JDT that the variable must be refreshed, and the listener is only there to make this happen sooner when possible; we only loose time if a change event occurs while the listener is not in place; this would deserve some explanation in the code anyway). Or, the listener is needed and we have an opportunity to get an inaccurate library if a change occurs while the listener is not active. This patch only addresses the problem of the concurrent reset of the user libraries, which I believe to be causing the issue noticed by the users. It is currently under test. Users interested in validating the patch on their code please speak up and let me know the best way for me to send you an org.eclipse.jdt.core.jar file (approx. 8Mb).
(In reply to comment #48) > This patch, built against R3_2_maintenance stream and currently under test, Tests are happy.
Please download patch from http://www.eclipse.org/jdt/core/patches/org.eclipse.jdt.core_3.2.3.z20070319-1111.jar. Opened separate bug 178027 for the listener-related issue.
Created attachment 61320 [details] simpler fix
Corresponding .jar file can be retrieved at http://www.eclipse.org/jdt/core/patches/org.eclipse.jdt.core_3.2.3.z20070319-1931.jar
Released for 3.3M6 in HEAD. Awaiting for Falk's feedback to release it in R3_2_maintenance stream.
Verified for 3.3 M6 upon version v_743. (Source based verification.)
(In reply to comment #52) > Corresponding .jar file can be retrieved at > http://www.eclipse.org/jdt/core/patches/org.eclipse.jdt.core_3.2.3.z20070319-1931.jar > What do I have to do to include this file/patch into Eclipse? Just copying into the pluginfolder does not work. Also the UI of eclipse does not help... Markus
(In reply to comment #55) > (In reply to comment #52) > > Corresponding .jar file can be retrieved at > > http://www.eclipse.org/jdt/core/patches/org.eclipse.jdt.core_3.2.3.z20070319-1931.jar > > > > What do I have to do to include this file/patch into Eclipse? 1. Exit Eclipse 2. Delete the existing org.eclipse.jdt.core_3.2.3.v_686_R32x.jar from the plugins directory 3. Add org.eclipse.jdt.core_3.2.3.z20070319-1931.jar to this same plugins directory 4. Restart Eclipse
I don't have a 3.2.3. Neither the Autoupdate shows a 3.2.3 release nor the eclipse website. This must be an internal release??
(In reply to comment #57) > I don't have a 3.2.3. > Neither the Autoupdate shows a 3.2.3 release nor the eclipse website. > This must be an internal release?? > Do not matter about 3.2.3 in the jar file name, it's just the version of the JDT/Core plugin which is 'one step beyond' the Eclipse version one... Just take this jar, put it where indicated and this will work :-)
Using eclipse 3.3RC2 the problem occurs any more but possibly not as frequently as before and not affecting as many libraries as before. May it have influence that I use not a clean new eclipse but the old configuration files?
Fix backported to R3_2_maintenance. An update for 3.2.x is available at: http://www.eclipse.org/jdt/core/r3.2/index.php#UPDATES
(In reply to comment #54) > Verified for 3.3 M6 upon version v_743. > (Source based verification.) >
