Bugzilla – Full Text Bug Listing
| Summary: | Debugger unable to resolve variables | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Alex W <awang060843> | ||||
| Component: | Debug | Assignee: | JDT-Debug-Inbox <jdt-debug-inbox> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | Michael_Rennie, sarika.sinha | ||||
| Version: | 4.4 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | Macintosh | ||||||
| OS: | Mac OS X | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Using your example project it looks like good old bug 45507 - we do not look up / resolve variables from the parent container of an anonymous type. Marking as a dupe. *** This bug has been marked as a duplicate of bug 45507 *** Just wondering, would package-private classes also fall under bug 45507? When I try to debug a method in ByteBufferAsCharBufferB I'm also getting the "cannot be resolve to a variable" message. Which variable from ByteBufferAsCharBufferB and in which method ? public String toString(int start, int end) Stepping through the lines in this method produces no updates in the Variables view in the Debug perspective. Inspecting any of the variables in the method produces "___ cannot be resolved to a variable", even after the debugger line (is that the term?) passed that line of code. In addition, the input arguments to the method are rendered as arg0 and arg1 in the Variables view, instead of by the names given in the signature. (In reply to Alex W from comment #5) > In addition, the input arguments to the method are rendered as arg0 and arg1 > in the Variables view, instead of by the names given in the signature. This would mean that the code you are stepping in has not been compiled with debug attributes. You mentioned ByteBufferAsCharBufferB, which is a JDK class that is not built with debug attributes. Since JDK classes are not built by Eclipse, there is no way to add in the needed attributes. Perhaps a better dupe would be bug 126108 now that we know we are talking about JDK classfile debugging. *** This bug has been marked as a duplicate of bug 126108 *** Ah, I didn't realize that the JDK classes couldn't be debugged. I *thought* I had done so in the past before, but evidently that is not the case. I assume there isn't an easy way to get around this, as the download from Oracle is missing some sun.* packages, and I would need to recompile the OpenJDK C/C++ sources for JNI/JNA? Also a note: my original bug report I think was indeed related to bug 45507. The second part about JDK classes was mostly unrelated, save for the observation that the debugger did not function as expected. I just thought that the behavior might have been related, but my guess was incorrect. (In reply to Alex W from comment #7) > Ah, I didn't realize that the JDK classes couldn't be debugged. I *thought* > I had done so in the past before, but evidently that is not the case. I > assume there isn't an easy way to get around this, as the download from > Oracle is missing some sun.* packages, and I would need to recompile the > OpenJDK C/C++ sources for JNI/JNA? > To be honest I have never tried building OpenJDK, but maybe this file would help: http://hg.openjdk.java.net/jdk9/jdk9/file/824ca17eb07a/README-builds.html |
Created attachment 243147 [details] Project where the debugger doesn't work for me Eclipse 4.4 M7, build 20140508-1440, Java 1.8.0_05. When in debug mode, highlighting variables and opening the inspector with COMMAND + SHIFT + I brings up "___ cannot be resolved to a variable". Already checked preferences, and all checkboxes for options used by the debugger in Java --> Compiler are checked. This problem appears to be somewhat sporadic; the debugger works in one project, but doesn't in another. Attached is one project where the debugger doesn't work for me. Breakpoint was placed on default package --> Test.java line 19. Please excuse the mess; the project was primarily a place for me to try out things. I don't expect this to be reproducible, but just in case...