java.lang.Exception verifyerror: Mauvais type sur des opérandes de pile dans la méthode com.soleil.net.httpserver.le spi.HttpServerProvider
J'ai été frappé par ce problème et réussi à le réduire à un petit fichier qui échoue jeter le java.lang.VerifyError
lorsqu'il est appelé à partir de Fourmi avec fork
ensemble de false
dans le <java>
tâche, mais réussit quand fork
est fixé à true
.
Le fichier autonome est:
package foo;
import javax.xml.ws.Endpoint;
import javax.jws.WebService;
@WebService
class Hello {
public String sayHello() {
return "hello";
}
}
public class FooMain {
public static void main(String args[]) throws Exception {
Object implementor = new Hello();
String address = "http://localhost:9000/SoapContext/SoapPort";
Endpoint.publish(address, implementor);
}
}
Lorsqu'il est invoqué avec Ant et fork
ensemble de false
il lance:
[java] java.lang.VerifyError: Bad type on operand stack
[java] Exception Details:
[java] Location:
[java] com/sun/net/httpserver/spi/HttpServerProvider$1.run()Ljava/lang/Object; @27: invokestatic
[java] Reason:
[java] Type 'sun/net/httpserver/DefaultHttpServerProvider' (current frame, stack[0]) is not assignable to 'com/sun/net/httpserver/spi/HttpServerProvider'
[java] Current Frame:
[java] bci: @27
[java] flags: { }
[java] locals: { 'com/sun/net/httpserver/spi/HttpServerProvider$1' }
[java] stack: { 'sun/net/httpserver/DefaultHttpServerProvider' }
[java] Bytecode:
[java] 0000000: b800 2599 0007 b800 27b0 b800 2699 0007
[java] 0000010: b800 27b0 bb00 1a59 b700 2ab8 0028 57b8
[java] 0000020: 0027 b0
[java] Stackmap Table:
[java] same_frame(@10)
Lorsqu'il est invoqué avec fork
ensemble de true
il réussit. L'exception spécifique VerifyError
surtout lorsqu'il est combiné avec "Bad type on operand stack
" points à un bug du compilateur de ce que j'ai lu, mais pourquoi devrait-il réussir ou échouer selon le fork
attribut de la <java>
tâche Ant est au delà de moi. Toutes les pensées? Je suis en cours d'exécution Ubuntu 12.04
avec la suivant des outils java:
$ java -version
java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) Server VM (build 24.0-b56, mixed mode)
$ javac -version
javac 1.7.0_40
$ ant -version
Apache Ant(TM) version 1.8.2 compiled on December 3 2011
$ ant -diagnostics | grep java.vm
java.vm.version : 24.0-b56
java.vm.vendor : Oracle Corporation
java.vm.name : Java HotSpot(TM) Server VM
java.vm.specification.name : Java Virtual Machine Specification
java.vm.specification.vendor : Oracle Corporation
java.vm.specification.version : 1.7
java.vm.info : mixed mode
mise à jour importante
Lorsqu'il est appelé à partir de Fourmi avec fork
ensemble de false
j'ai aussi ajouter explicitement /usr/lib/jvm/jdk1.7.0/jre/lib/rt.jar
du CLASSPATH pour déclencher le VerifyError
exception. Sinon, il s'arrête avant d'atteindre le point avec:
javax.xml.ws.WebServiceException: Provider com.sun.xml.internal.ws.spi.ProviderImpl not found
Bien sûr, d'avoir à ajouter rt.jar
dans le CLASSPATH est puissant étrange, surtout depuis qu'il est la rt.jar
de la java
version que j'utilise.
ant -diagnostics | grep java.vm
dire?Ceci est très probablement dû à un fichier jar ou inadéquation de certaines de ces.
mis à jour le post
OriginalL'auteur Marcus Junius Brutus | 2013-09-19
Vous devez vous connecter pour publier un commentaire.
Ceci est probablement dû à l'incompatibilité entre les versions de java, je vois que vous êtes de course 1.7.0_40 et 1.7.0_24. Assurer JAVA_HOME est définie à l'1.7.0_40 JDK avant d'invoquer l'Ant. Voir le post suivant pour plus d'informations sur la façon de le faire. Comment puis-je changer la JAVA_HOME pour ant?
which javac
etwhich java
produire? Est la cible d'un lien symbolique? Si oui, alors où est-il point?vous avez raison, un pot a été faite par 1,8 et je courais, avec 1,7
OriginalL'auteur disrvptor
Bien, le plus probable, c'est juste une compilateur bug, voir http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8006684
Et il n'a pas vraiment d'dépendent de la fourche à la propriété selon votre description, seul le classpath.
OriginalL'auteur user3603546
Lorsque la classe est chargé des procédures de vérification sont effectuées. Si le byte code a été généré avec les erreurs du chargeur de classe pourrait soulever une exception verifyerror.
J'ai eu le même problème. Pour le résoudre:
1.8.0_75
2.2
->3.2.4
résolu le problème.OriginalL'auteur Azee