Summary: | Verification error | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Darin Wright <darin.eclipse> |
Component: | Core | Assignee: | Philipe Mulet <philippe_mulet> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P1 | CC: | jerome_lanneluc |
Version: | 2.0 | ||
Target Milestone: | 2.0 M1 | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Whiteboard: |
Description
Darin Wright
2001-10-12 14:39:25 EDT
I've got a similar problem running Core Test Cases. When compiling with 204 I cannot run and get the following stack trace. When compiling with 202a I can run on both 202a and 204. I can provide further information if necessary. 2 org.eclipse.core.runtime 2 Problems occurred when invoking code from plug- in: org.eclipse.core.runtime. java.lang.VerifyError: (class: org/eclipse/core/internal/resources/Workspace, method: delete signature: ([Lorg/eclipse/core/resources/IResource;ZLorg/eclipse/core/runtime/IProgressMon itor;)Lorg/eclipse/core/runtime/IStatus;) Localvariable 5 contains wrong type at org.eclipse.core.resources.ResourcesPlugin.constructWorkspace (ResourcesPlugin.java:91) at org.eclipse.core.resources.ResourcesPlugin.startup (ResourcesPlugin.java:134) at org.eclipse.core.internal.plugins.PluginDescriptor$1.run (PluginDescriptor.java:644) at org.eclipse.core.internal.runtime.InternalPlatform.run (InternalPlatform.java:814) at This bug was introduced when dealing with another verification error: 1GDS7IP: ITPJCORE:WIN2000 - VerifyError related to a local index computation Problem comes from the fact that it appears that bytecode verifiers want: (1) secret try return addresses must be allocated after any local variables in the method (2) variables local to a finally block need to be allocated behind the ones from the matching try block. Fixed in HEAD. Issuing a patch for 204 (not the optimal, simply reverting to <204 behavior for bug introduced try statement). The new code needs more testing. The old code (<203) did not do either one of these. 204 dealt properly with (2) but since it did not do anything special for return addresses, then many more code patterns broke (1) since return addresses reused the same location, like the test cases mentionned on this PR. |