Community
Participate
Working Groups
Eclipse 200211261143 I am debugging Eclipse walking through some code that I have in my workspace. I come to a method that is not in my workspace. I step into it. I get a dialog saying it can find the source and I click on cancel. I step out of this method back into code that is in my workspace. However, suddenly the debugger can't find the source anymore. Even though it was just recently in that code.
Does this happen on MacOS X? (Platform says PC, OS is MacOS X)
Currently I am developing on the Mac - I have changed the Platform field accordingly. This may happen on other platforms, I have not had time to check.
Clarification: Do you mean that changing the "Platform" field has fixed the problem? I tried a scienario, debugging VectorTest (JUnit), on Windows with the IBM1.3.1 JRE. I stopped at a breakpoint in a tests case, and then selected the following stack frame (for which there is no source): java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object[]) line: not available [native method] I was prompted to find source, but I simply pressed, OK. Then I selected a frame that had source, and source was found as expected.
By "platform" I am referring to the Platform field in Bugzilla. Yes it is still a problem. I have tried a similar thing on Windows and the problem did not occur. I did not press OK but rather Cancel because none of the source locations was suitable. The key is that there was no source for the code I stepped into (even after the dialog came up because I hit cancel) but when I stepped back out into code that did have source, the source could no longer be found.
Joe, please try to reproduce on the Mac.
Test case: OSX 10.2 Eclipse 20030115 Create HelloWorld program. Create launch config for HelloWorld and remove JRE from source lookup Set breakpoint on printline. Debug. At breakpoint, step into println. The attach source dialog appears. Hit Cancel. Dialog disappears, and source window for PrintStream appears with message that source cannot be found. Hit F7 to step out of println method, or hit F6 multiple times. Excecution returns to HelloWorld at next line, and all appears well. Veronika, when you say you step into a method not in your workspace, do you mean a method in an external jar, or something else?
In my workspace, I only have the org.eclipse.swt and org.eclipse.swt.carbon plugins. Since the SWT plugins do not rely on any other plugins, I have no other plugins loaded and the classpath does not reference any external jars. When I launch eclipse for debugging, I go to the Debug... dialog. In the plugins and fragments tab I select "Choose plugins and fragments to launch from list" and I select the swt plugins from the Workspace plugins and all the rest of the plugins from the External plugins. Thus I do not have any source for the other plugins in my workspace. While debugging, I may step into something like an event handler which is not implemented in SWT code but rather in something like the UI workbench code. That is when I get the problem. The workbench code can not be found and when I step out of the workbench code back into SWT code, the SWT "source" can not be found either (even though I was just there a few steps ago). I have also had this happen occasionally on Windows.
Veronika, I understand your setup now, but can you suggest someplace in SWT to set a breakpoint so I can step out of SWT and back in? Thanks.
EventTable.sendEvent (around line 77) is a good place.
What VM are you using to reproduce this behaviour? I haven't been able to reproduce it using JDK 1.3.1. Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-root_1.3.1_020714- 12:46) Java HotSpot(TM) Client VM (build 1.3.1_03-69, mixed mode)
OK, I can reliably reproduce this now using the 1.3.1 VM, but the way I reproduce it is to hit "OK" in the first source attach dialog instead of 'Cancel'. Hitting Cancel nevers seems to cause the problem. Hitting OK would seem to be semantically equivalent to hitting Cancel because nothing is selected in the source attach dialog.
I tried this with jdk1.4.1 and Eclipse build 20030121 on windows 2k. I see the same results if I use Joe's O.K. button trick. Suggest marking as OS-ALL.
Tried turning off the "re-use editors" preference. This had no effect on the source lookup.
It appears that source attachment in general is broken. Jed & I have determined that the culprit is a change made for bug 23408. Specifically, the call to JavaUISourceLocator.this.initializeDefaults(configuration); in the method JavaUISourceLocator.showDebugSourcePage(). This call appears to reset the source lookup path to be JRE-related entries, WITHOUT the project(s). Thus, source lookup fails any time the user clicks OK in the attach source dialog. Darin, can you confirm this analysis? If this is correct, what is the best course of action?
I know there is a problem when OK is pressed - that is a known PDE bug. PDE is using our source lookup dialog, which re-sets their source lookup path to only contain JRE entries (since they are not using the standard java source lookup attributes on their launch config) - see bug 24793. This also sets the source lookup path for the rest of the debug session. However, Veronika's report says she pressed the CANCEL button. I have been able to reproduce that problem. We need a final verification... Veronika - if you start a new debug session, hit a breakpoint, step into code that you do not have, and press CANCEL when the dialog appears, do you still exhibit the "source not found" problem when you step back into SWT source?
Just to be clear, neither Jed nor I could reproduce the problem hitting CANCEL, despite numerous attempts.
I will try CANCEL versus OK as soon as I get a chance.
Veronika, can we mark this as a duplicate of bug 24793 ?
Yes - I think this is a duplicate of 24793. I tried OK versus Cancel and I get the same result as you do.
*** This bug has been marked as a duplicate of 24793 ***
