Bugzilla – Full Text Bug Listing
| Summary: | Java debugger runs stale code, refuses to refresh | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Graham Leggett <minfrin> | ||||||
| Component: | m2e | Assignee: | Project Inbox <m2e.core-inbox> | ||||||
| Status: | CLOSED WORKSFORME | QA Contact: | |||||||
| Severity: | major | ||||||||
| Priority: | P3 | CC: | darin.eclipse, igor, kirenpillay1, Leo.Wandersleb, Michael_Rennie, remy.suen | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Graham Leggett
Created attachment 170126 [details]
Screenshot showing the problem
The screenshot shows the problem. A comment and a line of code have been added, but the debugger stops on the comment - the location of the next line before this amendment was made.
Just to confirm, the mvn clean install eclipse:eclipse was done on both the dependent jar, and on the war that depends on the jar, at the same time. The pom file is definitely pointing at the correct jar, the timestamps from the maven build show clearly that both the dependent jar is being rebuilt, and the war is being rebuilt. Eclipse insists on running a stale copy of the code. If you replace class files instead of jars, does it work? For example, debugging and modifying a simple application with loops and nested method calls. Do you have build automatically turned on? Does cleaning your projects help? Hot code replace works on class files. It's not clear from this bug report what sort of runtime (debug-time) you have. However, hot swap listens for .class file changes in the SDK and they transfers the new bytes to the attached VM that is running in debug mode. There is mention of jars here... so I'm not sure what setup you are using. As well, what type of launch configuration is this? Is it plain Java or something else? Jar A is depended on by war B, which is being debugged from within tomcat, which is configured as a "server" within Eclipse. I am able to set a breakpoint in jar A, and the debugger stops at the breakpoint. I am able to step through the code, but as soon as I reach the modification, I see the code being traced is from before the addition of the two lines (one line and a comment). I can see this because the code stops two lines above the actual code on each step from this point on. I have no idea where this phantom old class file is coming from. Jar A, and war B are built with maven in it's default layout, and maven tells eclipse about jars and dependencies with mvn eclipse:eclipse. Viewing the "referenced libraries" section shows the correct version of jar A listed. Thinking of other things to flush out, I find "clean tomcat work directory". Again, makes no difference, the phantom class file still exists. I try "clean" of war A from the Eclipse "project" menu, and now tomcat complains that the servlet class from war A is not found (java.lang.ClassNotFoundException). I refresh war A, no difference, tomcat is not happy, the class is still not found. It definitely looks like something during the build process is borked. After a "clean", Eclipse now refuses to rebuild the class file, and shows no visible warning or error that it encountered a problem of any kind. The "clean" usually automatically triggers an automatic rebuild, but the job seems to complete very quickly, as if the automatic rebuild isn't being done. The checkbox on project -> build automatically is checked. When selecting war A, I note that project -> build project is greyed out. No clue is given for why it should be greyed out. I select other java projects and note that projects -> build project stays greyed out for them too. I select a C project, and the project -> build project appears correctly. I select a java project again, and project -> build project greys out again. This is sounding less like a debug issue and more like a building issue. What tooling are you using to build? is it stand alone JDT, WST...? I'm not familiar with the Eclipse acronyms, so I am not sure. Maven's eclipse:eclipse goal, as I understand it, configures the Eclipse target directory for the class files to be the same as the maven target directory for the class files, and from that point on, I use the native build in Eclipse to do the builds, so that hot-code-replace works (etc). This doesn't seem to be happening though, because an mvn clean has no effect on Eclipse - the phantom class files remain, and now that the phantom class files have been blown away, mvn install doesn't cause those files to come back as you would expect it to. This means Eclipse is referring to the class files "somewhere else" on the disk, and to date I have found no functionality in Eclipse to show where these class files are being created / stored. I have attached the .log file from after Eclipse starts up. There is some stuff in there that may be related, or may not be, it isn't clear. Created attachment 170203 [details]
Eclipse .log file after Eclipse startup and attempt to clean the war file.
Eclipse .log file after Eclipse startup and attempt to clean the war file.
(In reply to comment #8) > Created attachment 170203 [details] > Eclipse .log file after Eclipse startup and attempt to clean the war file. > > Eclipse .log file after Eclipse startup and attempt to clean the war file. Is there any progress on this issue? I'm come up against in the SpringSource Toolkit (STS) 2.5.1 (based on 3.6). I have (reluctantly) moved to Netbeans, I hope this is solved soon. I am using maven m2eclipse. /bump :(( I've been fighting some hours to get something similar sorted out. Eclipse hung. As on my setup this can quickly run into the whole system hanging what happens some once in a month, I ran kill -15 on the java process. Since then I have stale code problems like described above. I tried everything a hundred times: * refresh * project clean * eclipse -clean * revert code (I got weird compile errors that got resolved after doing a change and saving again.) * rename the file A.java to B.java (the debugger jumps around in the B file as if it was the old A file) I'm developing Android. I will move to a fresh work space next and if that doesn't help, resinstall eclipse ... :( Ok, so now I opened eclipse with a new workspace and did a new checkout of my project. Somehow magically it seams to still step through it like it was the code from yesterday in the other workspace. How can it know of it?
Please verify if this is suspicious. After pressing F6 when the debugger stops at //breakpoint, it makes no sense to continue at //step1, 2 and 3. Well, 1, yes but not 2 and 3. After 2, 3 would be unreachable.
adapter.setViewBinder(new ViewBinder() {
public boolean setViewValue(View view, Cursor cursor, int column) {
if (column == 6) { // breakpoint
TextView dueLabel = (TextView) view;
long dueTime = cursor.getLong(dueTimeColumnIndex);
String date = dateFormat.format(dueTime);
dueLabel.setText(date);
return true;
} else if (column == 4) {//step 1
TextView cardSetLabel = (TextView) view;
String name = cursor.getString(cardSetColumnIndex);
name = name.substring(0, Math.min(15, name.length() - 1));
cardSetLabel.setText(name);//step 2
return true;
}
return false;//step 3
}
});
After using a freshly downloaded eclipse with a freshly installed ADT on that last workspace, either some very weird bug survived via this workspace or it is the Android SDK. Ok, a fresh install of the Android SDK didn't fix the problem. I'm pretty much lost on this. Will wipe out all Android and Eclipse and start with a fresh workspace. If there is any spot the bug could also come from, I would really appreciate hints. Please ignore/delete all my comments. I struggled some 8h with unreachable code being optimized out of the binary. (In reply to comment #13) > Please ignore/delete all my comments. I struggled some 8h with unreachable code > being optimized out of the binary. Thanks for reporting back, it does sound like a problem with ADT... r.e. comment #8 The log file does not contain anything about the debugger (thanks for attaching it though). I agree with Darin on this, that it is likely a build issue and not a problem with the debugger. The debugger reacts to .class file resource changes and if we don't get those notifications we don't perform HCR (hot code replace). Lets send this over to the Maven bug-box since it sounds like thats how you are controlling your build - perhaps they have some thoughts. First, it appears that original reporter uses maven-eclipse-plugin, which is not related to m2e and is actually incompatible with m2e. For the problems observed with m2e, we'll need a sample project and steps to reproduce the problem in order to trouble this. The problem must be reproducible with a fresh clean install of Juno M4 java epp package (we can't debug STS and other thirdparty distributions). Closing old/stale bugreports. |