Unable to start the appserver - java.lang.VerifyError: JVMVRFY012 stack shape inconsistent;

Products

• CA Application Performance Management Agent (APM / Wily / Introscope)
• INTROSCOPE

Issue/Introduction

Unable to start the appserver, the below exception is reported in the application server log: "java.lang.VerifyError: JVMVRFY012 stack shape inconsistent"
Example 1:
[05/04/17 07:33:24:553 BST] 00000001 ContainerHelp E   WSVR0501E: Error creating component com.ibm.ws.ssl.core.SSLComponentImpl
java.lang.VerifyError: JVMVRFY012 stack shape inconsistent; class=com/ibm/ws/ssl/config/ManagementScopeData, method=<init>(Ljava/lang/String;)V, pc=22
at com.ibm.ws.ssl.config.ManagementScopeManager.currentScopeContained(ManagementScopeManager.java:324)

Example 2:
[INFO    ] FFDC1015I: An FFDC Incident has been created: "javax.resource.ResourceException: java.lang.VerifyError: JVMVRFY012 stack shape inconsistent; class=com/ibm/msg/client/wmq/internal/WMQConnection, method=<init>(Lcom/ibm/mq/jmqi/JmqiEnvironment;Lcom/ibm/mq/jmqi/JmqiMQ;ILcom/ibm/msg/client/jms/JmsPropertyContext;)V, pc=22 com.ibm.ws.ejbcontainer.mdb.internal.MDBRuntimeImpl 782" at ffdc_17.05.03_11.16.

Environment

All Java Agent releases

Cause

Defect information:
This issue is related to DE275471 - US309901 : constructor instrumentation broken with latest Oracle and IBM JVM 1.8 SR4 (8.0.4.0), 7 R1 SR4 (7.1.4.0), 7 SR10 FP0 (7.0.10.0)
CA APM Development worked with IBM Support to resolve the issue : PMR# 36599,756
The response was that the full instrumentation of constructors is discouraged.

To summarize:
The root cause is vagueness in java specification regarding the bytecode validation of class constructors. 
When the agent add instrumentation to constructors the code that is added to measure execution time has to pass JVM byte code validation. 
Unfortunately validation rules were somewhat vague and different versions of JVMs interpreted these rules differently. 
As a result our instrumentation that passed in older JVM versions, does not pass in validation in some newer Versions. 
There is also difference in different vendor interpretation of the specification.

What is the impact:
This problem with ctor instrumentation will affect the instanceCounter you should not miss anything except InstanceCounts metrics.
 

Resolution

We have introscope.autoprobe.constructor.policy property that allows us to adjust our constructor instrumentation code so it passes these different spec interpretations of JVMs.

The class that breaks is not part of core instrumentation but gets instrumented by our intelligent deep tracing mechanism. 
There are several options to work around this problem.

(1) Adjust the constructor instrumentation policy. 
(2) Lower the intelligent instrumentation threshold so this method does not get instrumented.
(3) Explicitly Skip this class for instrumentation. 

About (1) in 10.5.2.15 (GA release) and pre-releases "introscope.autoprobe.constructor.policy" is default = "Full"
You can try to reduce the constructor instrumentation code to Partial as below:

1. Stop the Application Server
2. Open the AGENT_HOME/core/config/IntroscopeAgent.profile, 
3. Add the below 2 hidden properties:
introscope.autoprobe.constructor.policy=Partial
introscope.autoprobe.constructor.instrumentation.affected.vendors=Oracle,SAP,IBM
4. Start the Application Server

NOTE: introscope.autoprobe.constructor.instrumentation.affected.vendors has been deprecated starting from 10.5.x

If this fails. It is possible that its entirely new instrumentation bug. In that case collect the dump of instrumented class by using this java command line option:

If you are using IBM JVM add the following jvm arguments:
-Dintroscope.agent.instrumentation.verification.debug=jdk/nashorn/internal/runtime/ScriptEnvironment -Dintroscope.agent.instrumentation.debugdump.path=<valid and existing path on filesystem>

If you are using Oracle JVM, add:
-Dintroscope.agent.instrumentation.verification.debug=oracle/security/pki/OracleKSIdentityEntry -Dintroscope.agent.instrumentation.debugdump.path=<valid and existing path on filesystem>

This will dump the bytes of problem class into specified location before and after instrumentation. 
Open a Support case and include the output, these class files would allow us to diagnose the problem precisely. 

In the meantime, you can disable the instrumentation of constructors by setting introscope.autoprobe.constructor.policy=None as below:

1. Stop the Application Server
2. Open the AGENT_HOME/core/config/IntroscopeAgent.profile, 
3. Set introscope.autoprobe.constructor.policy=None 
4. Start the Application Server