Bug 68314 - VerifyError when using j9 VM
Summary: VerifyError when using j9 VM
Status: RESOLVED INVALID
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 3.1 M1   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-06-23 11:41 EDT by Milorad Stefanovic CLA
Modified: 2005-01-11 11:02 EST (History)
2 users (show)

See Also:


Attachments
The automatically generated JavaCC token manager (515.29 KB, application/octet-stream)
2004-07-16 10:49 EDT, Milorad Stefanovic CLA
no flags Details
Standalone java file that can be compiled (137.46 KB, application/octet-stream)
2004-07-22 13:52 EDT, Milorad Stefanovic CLA
no flags Details
Class file (43.74 KB, application/octet-stream)
2004-07-22 13:52 EDT, Milorad Stefanovic CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Milorad Stefanovic CLA 2004-06-23 11:41:59 EDT
I get a VerifyError every time I try to create a new instance of a specific
class. The class that j9 does not like is actually a token manager generated by
the JavaCC tool. When -Xj9 switch is not used, there is no problem and the
VerifyError does not occur.

The version information is as follows... Eclipse Version: 3.0.0, Build id:
200405140800 ... and the partial stack trace is provided at the end.

You'll probably want have a look at Bugzilla Bug 42692 "JavaCC files cause
VerifyError when compiled with Eclipse." However, 42692 indicates that it has
been fixed in Oct 2003.

Please let me know if this is a known problem, or if you need more information
to reproduce the problem.

Thanks!
--


java.lang.VerifyError
	at java.lang.Throwable.<init>(Throwable.java)
	at java.lang.Throwable.<init>(Throwable.java)
	at java.lang.VerifyError.<init>(VerifyError.java:48)
	at java.lang.ClassLoader.defineClassImpl(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java)
	at
org.eclipse.osgi.framework.internal.defaultadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java)
	at
org.eclipse.core.runtime.adaptor.EclipseClassLoader.defineClass(EclipseClassLoader.java)
	at
org.eclipse.osgi.framework.internal.defaultadaptor.DefaultClassLoader.findClassImpl(DefaultClassLoader.java)
	at
org.eclipse.osgi.framework.internal.defaultadaptor.DefaultClassLoader.findClass(DefaultClassLoader.java)
	at
org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.findLocalClass(AbstractClassLoader.java)
	at
org.eclipse.core.runtime.adaptor.EclipseClassLoader.findLocalClass(EclipseClassLoader.java)
	at
org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java)
	at
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java)
	at
org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.loadClass(AbstractClassLoader.java)
	at java.lang.ClassLoader.loadClass(ClassLoader.java)
Comment 1 Philipe Mulet CLA 2004-06-24 05:18:08 EDT
We need more information to reproduce the problem. Please attach an example of 
a file which would reproduce this issue.
Comment 2 Philipe Mulet CLA 2004-07-03 11:54:24 EDT
Please reopen once reproducing steps are available.
Comment 3 Milorad Stefanovic CLA 2004-07-16 10:49:12 EDT
Created attachment 13363 [details]
The automatically generated JavaCC token manager

The VerifyError that occurs with the -Xj9 flag on can be reproduced using the
attached JavaCC generated file (XQueryTokenManager.java). Thic file has one
particularly big method (jjMoveNfa_0), that contained a large number of
conditional branches (something like 700 case statements, as well as if/else
branches). The workaround solution is to move one large switch statement
containing some 200 cases into a different method, using parameters and class
fields to marshal the local variables. The new code is functionally the same as
before. However, if someone re-generates the parser code, the problem will
occur again.
Comment 4 Milorad Stefanovic CLA 2004-07-16 10:49:49 EDT
Please see the attcahed file for more information.
Comment 5 Olivier Thomann CLA 2004-07-21 21:49:10 EDT
Could you please provide the class XQueryConstants and the class SimpleCharStream?
I'd like to be able to compile your exact test case?
Comment 6 Milorad Stefanovic CLA 2004-07-22 13:52:06 EDT
Created attachment 13536 [details]
Standalone java file that can be compiled

VerifyError.java is the stand-alone source code that reproduces this defect.
VerifyError.class is the resulting class file compiled by Eclipse 3.0. The test
can be executed from the command line by typing "java -Xj9 VerifyTest". The
resulting message will be "The java class could not be loaded.
java.lang.VerifyError".  If the same is attempted without the -Xj9 switch, no
error occurs.
Comment 7 Milorad Stefanovic CLA 2004-07-22 13:52:44 EDT
Created attachment 13537 [details]
Class file
Comment 8 Olivier Thomann CLA 2004-07-27 10:53:28 EDT
I will investigate.
Comment 9 Olivier Thomann CLA 2004-07-28 20:34:06 EDT
This is due to a bug in the J9 VM. It has nothing to do with the Eclipse .class
file. Closing as INVALID.
The bug has been reported against the J9 VM. Future version of the J9 VM should
fix it.
Comment 10 Milorad Stefanovic CLA 2004-08-05 15:02:53 EDT
"The bug has been reported against the J9 VM. Future version of the J9 VM should
fix it."

Could you please provide the J9 bug name/number so I can check its status?
Comment 11 Olivier Thomann CLA 2004-08-05 16:03:30 EDT
VM bug. Closing as INVALID.