Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 Build Identifier: 20090619-0625 Every time I make modifications on two or more user libraries simultaneously (removing or adding jars), when I click on OK to save the changes Eclipse hangs showing "Compiling 0%..." and doesn't respond anymore. This not occurs if I modify only one user library at a time. Reproducible: Always
Would you have steps to reproduce ?
(In reply to comment #1) > Would you have steps to reproduce ? - Goto Window -> Preferences -> Java -> Build Path -> User Libraries - Click New... - Type a name for the user library and click OK - Click Add JARs... - Select some jars and click OK - Click again New... - Follow the same steps to create a new user library - Finally click OK on the Preferences window
Jay, please investigate.
I am unable to reproduce this bug with build I20090914-1800 - even when I use the same JAR files for both libraries. Does this happen with any particular jar files or doesn't matter?
It happens with any jar files... Try moving the jars to another directory, and then do the change for the two user libraries in the Preferences, when clicking finally OK the IDE always hangs ("Building workspace... 0%")
I am still not able to reproduce this behavior. Can you please try with the latest build or the one I mentioned in comment #4?
I have the same bug with multiple workspaces, with ~15..20 userlibs each. Also, i use identical eclipse installations on different machines. The problem is as follows: Whenever a library path must be adjusted with the userlib dialog, regardless how it was opened (project->properties... or windows->preferences...), this dialog won't close when hitting OK if 2 or more libs were changed. Also, if autobuilds are enabled, the build process will start in the background with the dialog still being open. Closing the dialog with windows topright X is possible, but building is now hanging endlessly and nothing happens. The java process (taskmanager) is at 0%. Eclipse can't be closed normally. The only way to get rid of the dead eclipse is closing the process by the taskmanager. If i closed the process and restart eclipse, the library changes are NOT done, thus i suspect the dialog saving procedure is faulty, at least for multiple changes at once. This happened at least 10 times to me during setup of same workspaces on different machines. The only working way is: Change one library each time, hit OK, call dialog again, which of course is a boring procedure. But even if i do so, saving the change to one library seems to be slow (compared to ganymede, autobuild off). Problem persists on 4 machines at the time of writing and occured from the very first fresh installation onwards. Eclipse Platform Eclipse Galileo Java EE IDE for Web Developers Version: 3.5.1.R35x_v20090910-9gEeG1_FthkNDSP2odXdThaOu9GFDPn83DGB7 Build id: I20090611-1540
Hi Mark, Can you please attach the affected project along with the libraries (only those required to reproduce the problem) ? I tried again with the build 20090619-0625 but no success yet. I need the project in question to have a close look at the project set-up, library dependencies etc.
Can you get me a stack trace, please? The following page should help you - http://wiki.eclipse.org/index.php/How_to_report_a_deadlock#Getting_a_stack_trace_on_Windows
Created attachment 152030 [details] Threaddump of deadlocked eclipse instance I seem to hit the same or a very similar bug and attach a threaddump. I'm trying to import a couple of userlibraries into a project already containing 10+ userlibraries. Attempting to import all libraries (30+) at once also hangs eclipse, with some libraries imported, the rest missing.
Created attachment 152051 [details] Proposed Patch Looks like a similar one as bug 249930. Only that it is SetContainerOperation in this case. Attaching the patch. Peter, please let me know if you need a plug-in patch to verify the fix.
Created attachment 152490 [details] Updated patch This is a better patch. I don't see a need the entire workspace root to be in the scheduling rule. Only the affected projects and the external folders project should be enough. If any of you can test this fix, it would be great. As I mentioned already, if you need a plugin patch, I can provide one.
Hi, I'd gladly test the patch, but I need someone to build a plugin jar from that. I can't build it myself.
Created attachment 152633 [details] Plugin patch Attaching the plug-in patch for verification. Please copy this to your <eclipse_root>/plugins folder (after taking a back-up of the original, of course) and restart eclipse. Once you eclipse is started, look for the following message in the <workspace>/.metadata/.log file. !MESSAGE Plugin patch for bug ...
I tried the patch on a fresh galileo install and was able to replace all existing 39 userlibraries without eclipse hanging. Unfortunately, I'm currently not able to reproduce the bug on my regular (unpatched) eclipse instances (which using jdtcore 3.5.1). I'm sending a note to my coworkers to watch for this bug and then try the patch on somebody else workspace where it's currently possible to reproduce.
I am not sure we can simply remove the synchronization from setUserLibrary(..). This method can also be called from outside the SetContainerOperation. Jérôme, could you please shed some light on this?
(In reply to comment #16) > I am not sure we can simply remove the synchronization from setUserLibrary(..). > This method can also be called from outside the SetContainerOperation. Note that setUserLibrary itself is not making any changes to the this.userLibraries object. It has to obtain a lock only because of the preference change event it triggers and subsequently the event listener (i.e JavaModelManager.EclipsePreferencesListener) invokes UserLibraryManager.updateUserLibrary(). And there is a synchronized block inside the updateUserLibrary anyway. Besides, the setContainerOperation can run long depending on the number of projects affected. So, I am not really sure if it's a good idea to keep the lock for such a duration.
It would have been nice to get Jérôme's comment on this one. I understand your explanation, but in this case should we also remove the synchronized block in org.eclipse.jdt.internal.core.UserLibraryManager.removeUserLibrary(String). I am targeting M5 for this bug.
Created attachment 154747 [details] Latest patch Including the changes to the UserLibraryManager#removeUserLibrary(String) as well.
Patch looks good to me. It would be nice to get feedback from nacho with the latest patch.
Nacho, Please let me know if you need a plug-in patch for the latest source patch attached.
Moving to 3.6M6.
Jay, please commit the change earlier in M6 (beginning of next week). Maybe Nacho can then try an I-build and provide feedbacks.
Released in HEAD for 3.6M6
Verified for 3.6M6 using build I20100305-101 by reviewing the source code
Verified.
The patch provided with comment 19 has been rolled back to fix bug 305043 (see bug 305043, comment 34). This bug is a duplicate of and fixed along with bug 260968. Keeping the FIXED state.
*** Bug 292827 has been marked as a duplicate of this bug. ***
