javawebspherejava-7ibm-was

java.lang.VerifyError: JVMVRFY012 stack shape inconsistent;

I am getting the following error while deploying a Maven project in WAS 8.5.5.

I have installed JDK 1.6 and 1.7 in WAS.

Error 500: org.springframework.web.util.NestedServletException: Handler processing failed; nested exception is java.lang.VerifyError: JVMVRFY012 stack shape inconsistent; class=com/xyz/simtools/savings/jaxb/SavingsInput_JAXB_Deserialization_Stub, method=write(ILjava/lang/Object;)V, pc=356

Things I noticed:

  1. In Tomcat, it's working fine
  2. There was some fix for this in IBM JDK according to this but it is still not working for me

Things I tried:

  1. Tried with both JDK versions in WAS.
  2. Read this link in IBM Forum
  3. Compiled my project in 1.5 and 1.7 and tried deploying

Am I missing something? Any other changes which I need to take care of?

Solution

  • I had the same issue, but in my case the problem and the fix was a different thing.

    (Possible) cause: My verdict regarding the cause of the problem was the conflict between two version implementations of the same API. At the design time, at my workstation (according established rules of the place I am), my IDE was using the SAAJ 1.4 of IBM JDK implementation to compile my Web Services classes. 

    IBM\jdk\jre\lib\rt.jar/com\sun\xml\internal\messaging\saaj\soap\SOAPDocumentImpl.class

    At runtime, using Tomee(Tomcat) 1.7.3, the same class were being loaded throughout the path:

    $TOMEE_HOME\lib\saaj-impl-1.3.18.jar/com\sun\xml\internal\messaging\saaj\soap\SOAPDocumentImpl.class

    And this was causing the verify error at the time the Web Services were executed:

    Workaround: Simply, take the saaj-impl-1.3.18.jar out of the Tomee's lib folder (move it). As the Tomee/Tomcat was using the same IBM JDK as my IDE, I found out that the conflict could be because of the saaj-impl-1.3.18.jar localized at the Tomee's lib folder. Moving out of there, make Tomee use the same implementation at runtime that were used at compile time (IBM JDK).

    Pay attention that I had this problem at my development workstation, is not a developlment/production(host) environment. Because of the rules of the workstation profile, this is the workaround that I found out works to me.