Bug 156443 - VerifyError
Summary: VerifyError
Status: RESOLVED INVALID
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: needinfo
Depends on:
Blocks:
 
Reported: 2006-09-06 17:32 EDT by Jim CLA
Modified: 2009-08-30 02:07 EDT (History)
1 user (show)

See Also:


Attachments
Classes (hopefully one that has a verify error). (11.42 KB, application/x-gzip)
2006-09-06 17:33 EDT, Jim CLA
no flags Details
Java class (4.99 KB, text/x-java)
2006-09-07 09:59 EDT, Jim CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jim CLA 2006-09-06 17:32:44 EDT
Thread [main] (Suspended (exception VerifyError))	
	TransSecs.<init>() line: 90	
	TransSecs.main(String[]) line: 125

Line 90 is this, so I assume that the error is in that class.
    MessageEditorFrame frame =  new MessageEditorFrame();

I can provide the class files (is there no way to upload them?)
Comment 1 Jim CLA 2006-09-06 17:33:57 EDT
Created attachment 49555 [details]
Classes (hopefully one that has a verify error).
Comment 2 Olivier Thomann CLA 2006-09-06 21:23:57 EDT
I'd like to reproduce the VerifyError, but I miss some classes.
Right now I need com.ergotech.transsecs.EditorFrame.

See the output:
D:\tests_sources>java com.ergotech.transsecs.secs.TransSecs
Exception in thread "main" java.lang.NoClassDefFoundError: com/ergotech/transsecs/EditorFrame
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)

I'll check the bytecodes.
Comment 3 Olivier Thomann CLA 2006-09-06 21:29:31 EDT
I don't see anything wrong.
What VM are you using?
Could you please provide all the .class files in order to run the test case myself?

Thanks.
Comment 4 Jim CLA 2006-09-07 00:16:16 EDT
I'll see if I can get you something to run.  Of course this is not a simple project. I'll try and cut it down, but would expect that will eliminate the error.  JDK is 1.4.2_05, but it doesn't immediately give the error outside of eclipse debugging.  Any differences in the eclipse environment that may cause this?  This has been a problem with this project for a while and I've been through all the obvious steps, cleaning, deleting classes, etc. etc., I've just updated to 3.2 to see if the problem still exists).  Running with noverify runs the project, for a while at least, usually it hits another verify problem or gets a JVM fault.  Other projects, bigger and smaller all run within the same eclipse environment with, supposedly, the same settings.

In the meantime, here's the rest of the exception, in case the bytecode can yield more clues:

Exception in thread "main" java.lang.VerifyError: (class: com/ergotech/transsecs/secs/MessageEditorFrame, method: loadProjectFile signature: (Ljava/lang/String;)V) Incompatible object argument for function call
	at com.ergotech.transsecs.secs.TransSecs.<init>(TransSecs.java:90)
	at com.ergotech.transsecs.secs.TransSecs.main(TransSecs.java:125)

  public void loadProjectFile (String fileName)  {
    ...
  }

is in the class.


Comment 5 Philipe Mulet CLA 2006-09-07 09:46:06 EDT
We likely will also need the source for TransSecs.
Comment 6 Philipe Mulet CLA 2006-09-07 09:46:31 EDT
BTW - which build ID are you running ?
Comment 7 Jim CLA 2006-09-07 09:59:33 EDT
Created attachment 49617 [details]
Java class
Comment 8 Jim CLA 2006-09-07 12:09:15 EDT
Version: 3.2.0
Build id: M20060629-1905
Comment 9 Jim CLA 2006-09-07 14:08:41 EDT
Trying to reproduce this in a smaller project I find the following.

1) I can't reproduce it in a small project/workspace (even if I add a huge classpath similar to the full project classpath).
2) If I strip the classpath in the main project/workspace the error goes away
3) If I go back to the project default classpath the VerifyError reappears in a totally consistent way. 
4) Other applications run with the default project classpath (which is large) without a problem.

Good news/bad news.  I can now run the app without a verify error and so the error is not a problem with code generation in the classes.

Following through further, if you're interested in doing so, is going to be challenging.  If you can provide me a way to get the full path that is running the application I'll add jars singly until I find out where the problem lies and then update with info about what on the classpath causes the problem.
Comment 10 Olivier Thomann CLA 2006-09-07 18:54:42 EDT
Could you please try a newer VM?
1.4.2 VM latest update is 1.4.2_12.
If you could attach a zip file that contain the complete test case that fails, it would be nice.
If you can't do it, because it is too big, let me know and we'll try to find another way to transfer the files.
Are you sure that you don't have duplicate classes on the classpath?

I am willing to help fixing this one, but I need a case I can reproduce and work with.
Thanks.
Comment 11 Olivier Thomann CLA 2006-09-08 15:57:10 EDT
Closing as REMIND.
Please reopen when requested information is available.
Comment 12 Denis Roy CLA 2009-08-30 02:07:02 EDT
As of now 'LATER' and 'REMIND' resolutions are no longer supported.
Please reopen this bug if it is still valid for you.