Summary: | AbstractMethodError while saving file | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Jeff McAffer <jeffmcaffer> | ||||||||
Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> | ||||||||
Status: | RESOLVED INVALID | QA Contact: | |||||||||
Severity: | normal | ||||||||||
Priority: | P3 | CC: | fraenkel, mdelder, min123, ruthdaly, steven.wasleski, thatnitind, tmusta | ||||||||
Version: | 3.0 | ||||||||||
Target Milestone: | 3.1 M2 | ||||||||||
Hardware: | PC | ||||||||||
OS: | Windows XP | ||||||||||
Whiteboard: | |||||||||||
Attachments: |
|
Description
Jeff McAffer
2004-06-01 14:29:33 EDT
Created attachment 11404 [details]
Java file which failed to save
When I tried to close the editor I got the trace below. Note that if I do subsequent changes, I get a similar (to the original) error but on saving again it appears to work. There is still something strange going on here as my code appears to compile ok (no errors) but is running strangely. Investigating more on that. !ENTRY org.eclipse.core.runtime 4 2 Jun 01, 2004 14:31:47.120 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.core.ru ntime". !STACK 0 java.lang.AbstractMethodError: org/eclipse/jdt/core/IJavaElement.getElementType( )I at org.eclipse.jdt.internal.core.JavaModelCache.peekAtInfo(JavaModelCach e.java:88) at org.eclipse.jdt.internal.core.JavaModelManager.putInfos(JavaModelMana ger.java:1449) at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement. java:586) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement. java:309) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement. java:295) at org.eclipse.jdt.internal.core.JavaElementDeltaBuilder.recordNewPositi ons(JavaElementDeltaBuilder.java:351) at org.eclipse.jdt.internal.core.JavaElementDeltaBuilder.buildDeltas(Jav aElementDeltaBuilder.java:135) at org.eclipse.jdt.internal.core.JavaModelManager.discardPerWorkingCopyI nfo(JavaModelManager.java:785) at org.eclipse.jdt.internal.core.DiscardWorkingCopyOperation.executeOper ation(DiscardWorkingCopyOperation.java:29) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperati on.java:700) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaMod elOperation.java:739) at org.eclipse.jdt.internal.core.CompilationUnit.discardWorkingCopy(Comp ilationUnit.java:414) at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvide r.disposeFileInfo(CompilationUnitDocumentProvider.java:864) at org.eclipse.ui.editors.text.TextFileDocumentProvider.disconnect(TextF ileDocumentProvider.java:516) at org.eclipse.ui.texteditor.AbstractTextEditor.disposeDocumentProvider( AbstractTextEditor.java:2931) at org.eclipse.ui.texteditor.AbstractDecoratedTextEditor.disposeDocument Provider(AbstractDecoratedTextEditor.java:1061) at org.eclipse.ui.texteditor.AbstractTextEditor.dispose(AbstractTextEdit or.java:2854) at org.eclipse.ui.texteditor.AbstractDecoratedTextEditor.dispose(Abstrac tDecoratedTextEditor.java:216) at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.dispose(JavaEditor. java:2919) at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.dispose( CompilationUnitEditor.java:1589) at org.eclipse.ui.internal.WorkbenchPartReference.dispose(WorkbenchPartR eference.java:391) at org.eclipse.ui.internal.EditorManager$Editor.dispose(EditorManager.ja va:1227) at org.eclipse.ui.internal.WorkbenchPage$5.run(WorkbenchPage.java:1189) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatfo rm.java:615) at org.eclipse.core.runtime.Platform.run(Platform.java:758) at org.eclipse.ui.internal.WorkbenchPage.disposePart(WorkbenchPage.java: 1187) at org.eclipse.ui.internal.WorkbenchPage.closeEditor(WorkbenchPage.java: 988) at org.eclipse.ui.internal.WorkbenchPage.closeEditor(WorkbenchPage.java: 947) at org.eclipse.ui.internal.EditorPane.doHide(EditorPane.java:95) at org.eclipse.ui.internal.PartStack.close(PartStack.java:339) at org.eclipse.ui.internal.EditorStack.close(EditorStack.java:201) at org.eclipse.ui.internal.PartStack$1.close(PartStack.java:74) at org.eclipse.ui.internal.presentations.DefaultPartPresentation$1.close ButtonPressed(DefaultPartPresentation.java:107) at org.eclipse.ui.internal.presentations.PaneFolder.notifyCloseListeners (PaneFolder.java:473) at org.eclipse.ui.internal.presentations.PaneFolder$2.close(PaneFolder.j ava:160) at org.eclipse.swt.custom.CTabFolder.onMouse(CTabFolder.java:2008) at org.eclipse.swt.custom.CTabFolder$1.handleEvent(CTabFolder.java:293) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:82) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:796) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:2716) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2382) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1363) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1334) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.jav a:253) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:141) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:96 ) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformAct ivator.java:334) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.ja va:273) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.ja va:128) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:85) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:58) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:60) at java.lang.reflect.Method.invoke(Method.java:391) at org.eclipse.core.launcher.Main.basicRun(Main.java:185) at org.eclipse.core.launcher.Main.run(Main.java:638) at org.eclipse.core.launcher.Main.main(Main.java:622) Note, this may be a VM thing. I am running with a partially baked setup. Suggest keeping this bug around in case others see similar things but don't panic Change bug state to RESOLVED/REMIND... *** Bug 72026 has been marked as a duplicate of this bug. *** Reopen since the problem appeared again. I have been seeing this problem only when I use J9. The Sun JDK doesn't seem to exhibit this problem, or hasn't in the past few days of use. To keep a copy of all of the data in one place, I'll put the JRE version that I see the problem on here too. This is the version output from the eclipse\jre\bin\java.exe -version command: java -version java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2) Classic VM (build 1.4.2, J2RE 1.4.2 IBM Windows 32 build cn142-20040810 (JIT ena bled: jitc)) I haven't been able to find a simple reproducible scenario for you. I tried making a copy of IES + the JRE + some of our code, but the error is never thrown. It appears frequently on the product, but never in the simple scenario. To try to get some information, I hacked the JavaModelCache class; every method that started with "switch(element.getElementType())" was surrounded in a try/catch block, and if an AbstractMethodError was thrown some additional information was sent to the log. I'll attach a copy of the JavaModelCache.java and the .log file containing the information. Please let me know if this information is useful for you, or if there is anything else that I can send in lieu of a simple reproducible scenario. Created attachment 14037 [details]
Log file with some additional information
Created attachment 14038 [details]
Modified file that typically encounters the AbstractMethodError
Just to clarify, I updated the jdtCore.jar file in org.eclipse.jdt.core with the JavaModelCache.class file. I don't know why an AbstractMethodError is being thrown because the types (ClassFile, and in some other cases CompilationUnit, BinaryMethod, and PackageFragmentRoot) have the getElementType() method defined. note that the VM version reported here is not for J9. I assume that when you are running the product the Java command line has -Xj9 on it. To get the correct version of the vm, please use java.exe -Xj9 -version. You're right, -Xj9 is used. Here's the version info. java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 2.2) IBM J9SE VM (build 2.2, J2RE 1.4.2 IBM J9 2.2 Windows 2000 x86-32 j9n142-2004081 0 (JIT enabled) J9VM - 20040806_1624_lHdSMR JIT - r7_level20040804_1801) This has been reported against Sidecar 2.2. I cannot read the defect but it was opened 2 weeks ago . SVT: eclipse "jdtuirefactoring" test throws AbstractMethodError Is there any information that I can provide, or something that I can do, that will help find a resolution for this Bugzilla? Seen in several components ... suggest that the priority be upgraded since it makes it impossible to use Java reflection in our tooling (RAD v6.0) when it arises. I tried to upgrade the Severity from "normal" to "critical" to reflect the affect that this bug has on our component, but I don't have sufficient permissions to do that. Can someone please upgrade the severity to "critical", please? It's "critical" instead of "blocking" because this bug doesn't happen 100% of the time, but when it happens it doesn't stop and the workspace has to be rebooted. Can I ask what's the outlook on a fix for this defect? Thanks. From the spec, an AbstractMethodError is * Thrown when an application tries to call an abstract method. * Normally, this error is caught by the compiler; this error can * only occur at run time if the definition of some class has * incompatibly changed since the currently executing method was last * compiled. The code in JDT Core was compiled without any problem. However the VM throws this error. This is obviously a problem with the J9 VM. You should report this problem to the VM provider. Sorry guys, but I don't see what JDT Core can do. Michael, with regard to comment #14. Do you have the J9 bug number from the J9 bugzilla system or the defect number from Hursley's CMVC system? Michael, nevermind. I found it in Hursley (76291). Report there indicates it only fails with the jit on. Has anyone seen it with the jit off? The defect report also says the bug has been fixed quite recently. I am querying as to which driver it will be in. I am told the J9 fix will be in the 20040826 build from Hursley. Please retry on that build level. I tried 20040826 and that appears to fix the problem. Thanks! Ruth, that is good news. Should this bug be resolved now? Thanks. Closing this bug as a VM problem. *** Bug 91440 has been marked as a duplicate of this bug. *** |