Java.lang.VerifyError

Question

I am getting the below error sporadically in my J2EE container. That is some time the container is getting up , without any problem , and some time the container is not coming up ,because of this error , have any one seen this error before...? what may be the cause ..? does it involves any class loader/security problem ..?

java.lang.VerifyError: (class: com/rsa/authagent/authapi/realmstat/AUTHav, method: a signature: (Lcom/rsa/authagent/authapi/authmsg/AUTHa0;)V) catch_type not a subclass of Throwable
        at java.lang.Class.getDeclaredFields0(Native Method)
        at java.lang.Class.privateGetDeclaredFields(Class.java:2259)
        at java.lang.Class.getDeclaredField(Class.java:1852)
        at java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1582)
        at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52)
        at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:408)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:400)
        at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:297)
        at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:531)
        at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1552)
        at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
        at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1634)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
        at com.rsa.authagent.authapi.realmstat.AUTHi.j(Unknown Source)
        at com.rsa.authagent.authapi.realmstat.AUTHi.<init>(Unknown Source)
        at com.rsa.authagent.authapi.realmstat.AUTHh.<init>(Unknown Source)
        at com.rsa.authagent.authapi.realmstat.AUTHg.<init>(Unknown Source)
        at com.rsa.authagent.authapi.AuthSessionFactory.a(Unknown Source)
        at com.rsa.authagent.authapi.AuthSessionFactory.<init>(Unknown Source)
        at com.rsa.authagent.authapi.AuthSessionFactory.getInstance(Unknown Source)
        at netx.esf.authentication.rsa.service.RsaAuthenticationServiceImpl.instantiateRsaAPI(RsaAuthenticationServiceImpl.java:1050)
        at netx.esf.authentication.rsa.service.RsaAuthenticationServiceImpl.start(RsaAuthenticationServiceImpl.java:73)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at arch.service.beans.RepBasedServiceBean.onMessage(RepBasedServiceBean.java:108)
        at arch.service.beans.RepBasedServiceImpl.onMessage(RepBasedServiceImpl.java:202)
        at arch.service.beans.RepBasedServiceImpl.message(RepBasedServiceImpl.java:229)
        at arch.CORBA.service.ServicePOA.local_message(ServicePOA.java:188)
        at arch.CORBA.Transport.sendLocalRequest(Transport.java:447)
        at arch.transport.StubProxy.send_managed_request(StubProxy.java:364)
        at arch.transport.StubProxy.invoke(StubProxy.java:205)
        at $Proxy15.start(Unknown Source)
        at arch.service.beans.RepositoryBasedServiceFactory.startDeployable(RepositoryBasedServiceFactory.java:423)
        at arch.service.beans.ServiceContainer$ServiceStarter.run(ServiceContainer.java:1392)
        at arch.service.beans.ServiceContainer$ThreadPool._run(ServiceContainer.java:2934)
        at arch.util.ThreadPool._runLoopBody(ThreadPool.java:213)
        at arch.util.ThreadPool._runForThread(ThreadPool.java:230)
        at arch.util.ThreadPool.access$000(ThreadPool.java:3)
        at arch.util.ThreadPool$1.run(ThreadPool.java:95)

Andreas Dolk · Accepted Answer · 2010-08-09 15:00:19Z

2

AUTHav.class is corrupt (sometimes?). Obviously some method is declared to throw something that is not a subclass of Throwable. Usually this shouldn't happen because a Java compiler would detect that problem and report an error. But maybe the class file is modified/instrumented or even generated at runtime and this introduces the sporadic error. Or you have a naming conflict and the classloaded sporadically sees a diffenent, non-Throwable class instead of the intended one.

If AUTHav.class is contained in some archive, you could have a look at the byte code (with javap or a decompiler) and check if you find a method with a suspicious throws argument.

So the byte code is obfuscated ... then it could be - and this is just a guess - that you have more than one version of the library inside your J2EE container. As the classes are obfuscated, there is a chance that the class names AUTHa7 and/or AUTHa1 are used for different (orginal) classes in different versions of the library. And then, if the classloader picks up both or maybe the wrong one at the wrong time, it could happen, that AUTHa7 and/or AUTHa1 are not Exceptions at runtime...

edited Aug 9, 2010 at 15:00

answered Aug 9, 2010 at 9:47

Andreas Dolk

115k20 gold badges185 silver badges275 bronze badges

Sign up to request clarification or add additional context in comments.

3 Comments

Mariselvam Over a year ago

I Checked the byte code of AUTHav.class . There is one method as below , public synchronized void a(AUTHa0 autha0) throws AUTHa7, AUTHa1 here , the AUTHa7 extends AUTHa1 and the AUTHa1 extends the 'Exception' class....so I feel nothing is suspicious here...do you have any idea ..?

Mariselvam Over a year ago

thanks Andreas , I checked my classpath , there are two class files with the same name from different JAR files . one of those two extends " Exception " that is the intended one , and the other one doent. Thank you.

Andreas Dolk Over a year ago

... unbelievable - it really was just are very wild guess. Glad to hear that it was a hit :-)

Michael Borgwardt · Accepted Answer · 2010-08-09 15:05:11Z

1

My guess: faulty hardware, especially RAM, causing the JVM to get corrupt bytecode. Usually it causes outright JVM crashes, but it's certainly a possibility worth checking out:

Memtest86+

answered Aug 9, 2010 at 15:05

Michael Borgwardt

347k81 gold badges491 silver badges726 bronze badges

Collectives™ on Stack Overflow

Java.lang.VerifyError

2 Answers 2

3 Comments

Comments

Your Answer

Linked

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

3 Comments

Comments

Your Answer

Sign up or log in

Post as a guest

Linked

Related