Bugzilla – Full Text Bug Listing
| Summary: | [hcr] Hot code replacement unuseable with generics | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Holger Mising name <private_lock> |
| Component: | Debug | Assignee: | JDT-Debug-Inbox <jdt-debug-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | darin.eclipse, Michael_Rennie |
| Version: | 3.6 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | stalebug | ||
This is working as expected. It is not possible to pop/re-enter the last method on the stack. In this case you are modifying "main". The debugger steps out and re-enters the modified method. In this case, we cannot step out of the main method and re-enter, as the debugger will have no where to re-enter from. The debugger also cannot pop native methods. This is a limitation of Java VMs. Thank you Mr. Wright!
Sorry, I've reduced the example to much ... but it gave the same error message. You've convinced me, that main() is a special case. Though I wonder why there is no error, if I first edit a comment, save and then edit the code for a second time?
Here is another Testcase:
public class Test<X> {
public static void aMethod() {
boolean flag = true; // breakpoint here
if (flag) {
System.out.println("debug");
} else {
System.out.println("normal");
}
}
public static void main(String[] args) {
aMethod();
}
}
Without the generic type parameter X the debugger will drop aMethod() and reenter it as expected. But in presence of generics hot code replacement fails with the aforementioned error-message.
It does not matter, whether aMethod() is static or not, or if it uses the generic type parameter.
BTW: I've reproduced the behavior with sun java, so I guess it's not specific to OpenJDK. -> I'm changing the summary
Needs investigation. Also fails on Windows when the type variable is present. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |
Build Identifier: 20100617-1415 Eclipse 3.6 Helios If I edit code and save while the debugger has paused execution in the vicinity (the same method), hot code replace fails for the openJDK. Expected behavior would be to drop the last frame from the stack and reenter the method again. If I only edit whitespace or add a comment, no error is shown and execution is aligned with the correct line-numbers. After such a change I can in a second step edit the code without getting the error-message. But the codechanges don't take effect for the currently running debug-session. Versions: java -version > java version "1.6.0_18" OpenJDK Runtime Environment (IcedTea6 1.8) (6b18-1.8-0ubuntu1) OpenJDK Client VM (build 14.0-b16, mixed mode, sharing) uname -a > Linux Samson 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 07:54:58 UTC 2010 i686 GNU/Linux Actually it is Kubuntu, so I'm running KDE 4.4.2 Reproducible: Always Steps to Reproduce: public class Test { public static void main(String[] args) { boolean flag = true; // breakpoint here if (flag) { System.out.println("debug"); } else { System.out.println("normal"); } } } 1. Place a breakpoint on line 4 of the given Test.java 2. Debug the program until the execution halts at the breakpoint 3. edit the source (any one of:) - change initialization of the flag from true to false - negate the condition of the if-statement - type a letter into one of the String literals in the System.out.println()s 4. and save 5. Dialog appears with: Obsolete Methods on the Stack <ClassName> at localhost:<Port> contains obsolete methods. Reason: The virtual machine was unable to remove all stack frames running old code from the call stack. The virtual machine is not supplying the debugger with valid data for those frames. Stepping into these obsolete frames may be hazardous to the target virtual machine. Do not show error when obsolete methods remain Continue Terminate Restart