Community
Participate
Working Groups
I have two different machines both with the same version of WSAD v5.1.2 (Eclipse v2.1.3) installed using the same J9 JVM build (20040510)... On one machine I can add/remove breakpoints without any problems from a class file that is contained in a JAR that has the source attached; However, on another machine with the same installation image the breakpoint image in the Java editor is not displayed when the breakpoint is added and the menu options for the breakpoint do not work afterwards. The breakpoint is added as I can see it in the 'breakpoint' view. I ran WSAD with -verbose:class and found the following: On the machine where the breakpoint fails to show the image in the Java editor the following happens: class load: org/eclipse/jdt/internal/debug/ui/snippeteditor/ISnippetStateChangedListener class load: org/eclipse/jdt/internal/debug/ui/actions/EvaluateAction class load: org/eclipse/jdt/internal/debug/ui/actions/ExecuteAction class load: org/eclipse/jdt/internal/debug/ui/display/IDataDisplay class load: org/eclipse/jdt/internal/debug/ui/actions/DisplayAction class load: org/eclipse/jdt/internal/debug/ui/actions/InspectAction class load: org/eclipse/jdt/internal/debug/ui/actions/WatchAction class load: org/eclipse/ui/internal/PagePartSelectionTracker$1 class load: org/eclipse/ui/internal/PagePartSelectionTracker$2 [end] On the machine where the breakpoint does show up the following happens: class load: org/eclipse/jdt/internal/debug/ui/snippeteditor/ISnippetStateChangedListener class load: org/eclipse/jdt/internal/debug/ui/actions/EvaluateAction class load: org/eclipse/jdt/internal/debug/ui/actions/ExecuteAction class load: org/eclipse/jdt/internal/debug/ui/display/IDataDisplay class load: org/eclipse/jdt/internal/debug/ui/actions/DisplayAction class load: org/eclipse/jdt/internal/debug/ui/actions/InspectAction class load: org/eclipse/jdt/internal/debug/ui/actions/WatchAction class load: org/eclipse/ui/IWorkbenchPage[] class load: org/eclipse/ui/internal/PagePartSelectionTracker$1 class load: org/eclipse/ui/internal/PagePartSelectionTracker$2 class load: org/eclipse/ui/internal/registry/MarkerImageProviderRegistry class load: org/eclipse/ui/internal/registry/MarkerImageProviderRegistry$1$MarkerImageReader class load: org/eclipse/ui/internal/registry/MarkerImageProviderRegistry$Descriptor class load: org/eclipse/debug/internal/ui/DebugPluginImages class load: org/eclipse/jdt/internal/debug/ui/ImageDescriptorRegistry class load: org/eclipse/jdt/internal/debug/ui/ImageDescriptorRegistry$1 class load: org/eclipse/jdt/internal/debug/ui/JavaDebugHover class load: org/eclipse/debug/core/model/IDebugTarget[] [end] I can understand if you will be unable to reproduce this so I was wondering if there is anything else that I can provide which may help to get to the bottom of why this is happening? I tried this with Eclipse v3.0 as well (not 3.0.1) and the results were the same.
Troy, is there anything in the .log file ?
No, there is nothing in the .log file.
Moving to Text since the breakpoint is present in the break point view, but not in the editor.
Does the debugger stop at the breakpoint? Do you set the breakpoint at exact the same location on both machines? Do you maybe see bug 35081?
Yes, the debugger will definitly stop at the breakpoint. That's the main reason for opening this defect as the end-user is left wondering why the debugger has stopped when there is no breakpoint marker visible in the editor. Yes, the breakpoint was set at the same location on both machines. The code in the JAR file was the following: public class HelloLib { public String sayHello(String name) { return "Hello " + name + "!"; } } I put the breakpoint on the 'return "Hello " + name + "!";' statement, so I don't think this is similar to bug 35081.
- Are both machines running Windows2000? - Is it exactly the same JAR? - Is the same source attached? - Is the project's build path setup identically? - When you tried Eclipse R3.0 did you use a new workspace? If not can you try with a new workspace? Also, if not, can you try to copy the workspace from the working machine to the one where it's not working and try whether you now see the breakpoint.
1) Yes, both machines are running Windows 2000 SP4. 2) Yes, it is exactly the same JAR (I just copied it from one machine to the other). 3) Yes, the same source JAR file is attached (same answer as #2). 4) The projects build path is the same (whatever the defaults are + the external JAR file being added). 5) Yes, I tried new workspaces when I tested in v3.0 (and v3.0.1). I tried copying over the workspace from the 'good' computer to the 'bad' computer and I am able to toggle the breakpoint successfully now. This is where the strange occurrences start happening... If I create a new workspace and Java project on the 'bad' computer (the one where setting the breakpoint fails) and use the original JAR files then I am able to reproduce the problem. However, if I then create another project (in the same workspace) using the JAR files that were copied to the 'good' computer (the one where setting the breakpoint is successful) and then copied back (via the workspace in (5) above) to the 'bad' computer then the problem does not occur... yet the JAR files are the same (the binary and source JAR files have the same size and timestamp as the original ones and none of them are corrupted). I also tried this separate in a new workspace and the result is the same. I can attach both sets of JAR files if you would like to try it out yourself.
Can you check in "good" and "bad" workspace a) which JRE is the default b) which JRE is on the project's Java build path
the good computer JRE (shipped with WebSphere Application Server v5.1.1): java.version=1.4.2 java.vm.info=J2RE 1.4.2 IBM J9 build 20040610 (JIT enabled) java.vm.name=IBM J9SE VM * There is only 1 Installed JRE (called 'java') so it is, of course, the default and is the 'JRE System Library' on the build path for the Java project. --- the bad computer JRE (shipped with WebSphere Application Server v5.1.1): java.version=1.4.2 java.vm.info=J2RE 1.4.2 IBM J9 build 20040610 (JIT enabled) java.vm.name=IBM J9SE VM * There is only 1 Installed JRE (called 'java') so it is, of course, the default and is the 'JRE System Library' on the build path for the Java project. --- I've also tried this on the Sun v1.4.2 and v1.5 JRE's as well and it is reproducible with it under the same scenarios as mentioned above.
Any additional insights from the Debug team?
In the "bad" scenario, does the Java editor have a vertical ruler?
Yes, the editor has a vertical ruler.
Please attach the jar files, or project export that demonstrates the problem, and tell us where to set the breakpoint.
Created attachment 15519 [details] JAR file without source.
Created attachment 15520 [details] source jar file.
Attached is a JAR file (HelloLib.jar) and it's source code in a separate JAR (HelloLib-src.jar). I could reproduce the problem by creating an empty Java project, adding the HelloLib.jar to the classpath, attaching the source to it, and then trying to add a breakpoint to return statement in the sayHello() method.
I can't reproduce this with the attached example - the breakpoint appears as expected.
I figured that would happen as I can only reproduce it on one of my machines here... so that's why I was wondering if there is any additional traces, information, etc. that I could provide you so that you may be able to take a guess as to what's causing it. Would it help if I created a remote desktop session on my machine for you to login and do whatever testing you need?
Can you see if the problem occurrs on 3.0? If not, I'd prefer not to invest too many cycles into the investigation.
Yes, I can reproduce this problem in Eclipse v3.0 (haven't tried v3.0.1 though). The situation is the same as with v2.1.3 - it works fine on one machine but not the other.
I can reproduce the problem by placing the HelloLib.jar in the root directory in the file system. The problem appears to be that java element handles are not restored to be the same element when the jar is in the root directory. When the classfile is asked for its handle when creating the ATT_HANDLE_ID memento in #addJavaElementMarkerAttributes(...), the folllowing is returned: =HW/C:\/HelloLib.jar<com.test(HelloLib.class The original element is as follows: HelloLib.class [in com.test [in C:\HelloLib.jar [in HW]]] class HelloLib When restoring from the memento, the element returned is: HelloLib.class (not open) [in com.test [in <project root> [in HW]]] Notice that the element created is in the project root rather than the external jar. Moving to JCORE for investigation.
(NOTE, this happens on 3.0, but I did not verify it happens in 3.1)
Fix should be backported to 2.1 maintenance stream (once available), and patch posted.
In 2_1_maintenance stream, changed JavaProject#getPackageFragmentRoot(IPath) to handle the case where the segment count is 1 but the path is different from the project path. Added regression test MementoTests#testExternalJarClassFileMemento()
Troy, you can find a patch at http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-core-home/r2.1/main.html#updates
Thank you very much for the patch - it has resolved this problem for the v2.1.3 release.
Thanks for letting us no that it solves the problem.
Released fix and test to HEAD and 3.0.x streams.
Tagging as candidate for 3.0.2, since it went to a 2.0 maintenance as well. Once verified in 3.0.2, target milestone should be reverted to 2.1.3 to reflect earliest delivery.
Verified for 3.0.2 for build M200502161722. Put target back to 2.1.3
Thanks!
