2010-08-09 5 views
0

Je reçois l'erreur ci-dessous sporadiquement dans mon conteneur J2EE. Cela fait un certain temps que le conteneur se lève, sans aucun problème, et un peu de temps, le conteneur ne se lève pas, à cause de cette erreur, quelqu'un at-il déjà vu cette erreur ...? quelle peut être la cause ..? cela implique-t-il un problème de chargeur/sécurité de classe?Java.lang.VerifyError

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) 

Répondre

2

AUTHav.class est corrompu (parfois?). Évidemment, une méthode est déclarée pour lancer quelque chose qui n'est pas une sous-classe de Throwable. Habituellement, cela ne devrait pas arriver car un compilateur Java détecterait ce problème et signalerait une erreur. Mais peut-être que le fichier de classe est modifié/instrumenté ou même généré lors de l'exécution et ceci introduit l'erreur sporadique. Ou vous avez un conflit de nommage et le classloaded voit sporadiquement une classe diffenente, non-Throwable au lieu de l'intention.

Si AUTHav.class est contenu dans une archive, vous pourriez avoir un oeil sur le code d'octet (avec javap ou un décompilateur) et vérifiez si vous trouvez une méthode avec un argument throws suspect.


Ainsi, le code octet est brouillées ... alors il pourrait être - et c'est juste une supposition - que vous avez plus d'une version de la bibliothèque dans votre conteneur J2EE. Comme les classes sont obscurcies, il est possible que les noms de classe AUTHa7 et/ou AUTHa1 soient utilisés pour différentes classes (originales) dans différentes versions de la bibliothèque. Et puis, si le classloader prend deux ou peut-être le mauvais au mauvais moment, il pourrait arriver que AUTHa7 et/ou AUTHa1 ne sont pas des exceptions à l'exécution ...

+0

J'ai vérifié le code octet de AUTHav.class. Il y a une méthode comme ci-dessous, public synchronisé void un (AUTHa0 autha0) throws AUTHa7, AUTHa1 ici, l'AUTHa7 étend AUTHa1 et l'AUTHa1 étend la classe 'Exception' .... donc je sens que rien n'est suspect ici. ..avez-vous une idée ..? – Mariselvam

+3

... Je déteste obtus bytecode –

+0

merci Andreas, j'ai vérifié mon classpath, il y a deux fichiers de classe avec le même nom à partir de différents fichiers JAR. l'un de ces deux étend "Exception" qui est l'un prévu, et l'autre un doent. Je vous remercie. – Mariselvam

1

Je pense: matériel défectueux, en particulier RAM, provoquant la JVM à corrompre le bytecode. Habituellement, il provoque des accidents de la JVM pure et simple, mais il est certainement possible la peine de vérifier:

Memtest86+

Questions connexes