Community
Participate
Working Groups
Build R2.0 When I open the debug perspective and go to add a java exception breakpoint, a progress dialog opens showing 'searching', and the program stops responding. I have to kill the program and restart. There is nothing writen to the .log file. I have a large-ish workspace (~250Mb) with plenty of compilation units, (and lots of compilation errors!) My workspace is available upon request.
Tim, can you put your zipped up workspace someplace where I can grab it? Also, what Java VM are you running Eclipse on, and could you provide a set of steps to reproduce the problem that begin with starting Eclipse on your workspace?
I'll send you a private e-mail telling you where to get the workspace. The machine is a Win2KProSP2, ThinkPad T23(PIII,1.2GHz), 1Gb RAM. The VM version is: java version "1.3.1" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1) Classic VM (build 1.3.1, J2RE 1.3.1 IBM Windows 32 build cn131-20020403 (JIT enabled: jitc)) launched as follows: C:\Eclipse\2.0\eclipse\eclipse.exe -debug -data "C:\Eclipse\workspace" - vm "C:\java\IBM JDK 1.3.1\jre\bin\java.exe" -vmargs -verbosegc -showversion - Xinitsh384K -Xms360M -Xmx640M -Xgcpolicy:optavgpause -Xmaxf0.85 -Xmine10M The steps to reproduce are quite straight forward: 1) Launch eclipse as above, 2) Switch to the debug perspective, 3) In the top right pane, try to set a breakpoint on an exception -- it only gets as far as searching... and hangs for multiple minutes at high CPU utilization, before I get fed up and kill it.
OK, I can reproduce the problem with your workspace. Debugging this, it appears that Eclipse is not in a hard loop, but is just doing a LOT of work indexing .java files as part of the search for Exception classes. This appears to be due to a bad index file. I deleted *.index in {WORKSPACE}/.metadata/.plugins/org.eclipse.jdt.core and this fixes the problem. Note that by doing this, you're forcing Eclipse to re-index all .java files. Thus, the first time you go to add an Exception breakpoint, you can expect a wait of several minutes while all classes in your workspace are indexed. You may also notice lesser waits on subsequent actions that directly or indirectly force indexing. But doing this with the provided workspace, I eventually got back to near instantaneous realization of the Add Exception dialog. I don't know if the problem with the indexes was caused by a bug in Java indexing or a passing neutrino. Please try this workaround, and let me know if it works. If it does, I will close this report. If you encounter the same problem in future, please file a bug against JDT/Core, as they are responsible for Java indexing.
Thanks Joe. My workspace is deteriorating, so many operations are taking a very long time (>5 minutes to open a .class file or drop to stack frame etc.) I'll attach a copy of the VM state during a long operation. Thanks for tracking down the invalid index -- I'll delete the indices and see if that fixes the workspace.
Created attachment 1764 [details] Dump of VM state during a long operation
Still on build R2.0, same workspace. I have deleted the indices and had them rebuilt (twice!) and am still having problems with setting a breakpoint -- though the symptoms are different now (I will open a new bug report if that is deemed more appropriate). When I get the list of exceptions to break on (which is progress) and type in an exception name, the list of exceptions includes a number that don't match the string I typed in -- plus the one that I did. I cannot select *any* of the exceptions from the list, and my .log file is growing rapidly. I'll attach the log file and you will notice the walkbacks in quick succession (look at the timestamps, which was when I brought up the list). This may be an SWT problem, but the effect is that I still cannot set an exception breakpoint. Any further suggestions?
Created attachment 1787 [details] log file from trying to set an exception breakpoint
Tim, I am working on this, and have made a little progress, but can't offer you any sort of workaround or solution just yet. Will keep you posted.
OK, the problem appears to have something to do with your JDK1.3.1 project. If I delete this project, I can add exceptions no problem. With this project in the workspace, some (not all) exceptions behave as you have noted -- clicking OK in the Add Exception Dialog does nothing. I believe this is a problem with the Java indexing, since with the JDK 1.3.1 project in the workspace, I also cannot open type (Ctrl-Shift-T) on the same exceptions that cannot be selected in the exception dialog. Doing so generates a "Could not uniquely map the type name to a type" dialog. Thus, I'd say the workaround for now is to remove the JDK 1.3.1 project from your workspace. It didn't appear as if any of the other projects were referencing it, so I'm not sure why it's there. You can look up source and reference JDK classes in launch configurations without bringing them in as source. I will re-assign this bug to JDT/Core to address the indexing issue. Just having a project that contains JDK source should not confuse the indexing.
Thanks for the update Joe, I agree that there is a problem with indexing when dealing with the JDK source, and/or multiple copies of the same package/class structure in multiple projects. For the record, I was working with the JDK so wouldn't expect it to reference anything else, and therefore the workaround to remove it is not ideal ;-)
Jerome - please investigate if search is impacted or only the indexing layer.
Tim, do you still have the workspace that causes the problem?
Or maybe Joe you still have it...
Without the workspace to reproduce the problem, I will close the bug.
Please reopen if you have the workspace that causes the problem.
