bytecode - Byte Code Verification failing with java.lang.VerifyError: Expecting a stackmap frame at branch target 11 . What does branch target 11 means? -
java 1.8 byte code verification failing when class getting loaded.below constructor of class snacontrol fails load. working fine when compiled using javac 1.6
public com.lucent.oms.sna.snacontrol(); descriptor: ()v flags: acc_public code: stack=2, locals=1, args_size=1 0: aload_0 1: invokespecial #1 // method java/lang/object."<init>":()v 4: aload_0 5: aconst_null 6: putfield #2 // field snaname:ljava/lang/string; 9: aload_0 10: iconst_0 11: putfield #3 // field snahealthstatus:z 14: aload_0 15: aconst_null 16: putfield #4 // field snapoa:lorg/omg/portableserver/poa; 19: aload_0 20: aconst_null 21: putfield #5 // field m_corbautil:lcom/lucent/oms/almapapi/util/corbautil; 24: aload_0 25: aconst_null 26: putfield #6 // field exsnmp:lcom/lucent/oms/exsnmp/exsnmpadapter; 29: aload_0 30: putstatic #7 // field snacontrolobj:lcom/lucent/oms/sna/snacontrol; 33: return linenumbertable: line 35: 0 line 25: 4 line 26: 9 line 28: 14 line 32: 19 line 33: 24 line 36: 29 line 37: 33 localvariabletable: start length slot name signature 0 34 0 lcom/lucent/oms/sna/snacontrol; error :
exception in thread "main" java.lang.verifyerror: expecting stackmap frame @ branch target 11 exception details: location: com/lucent/oms/sna/snacontrol.<init>()v @4: ifnonnull reason: expected stackmap frame @ location. bytecode: 0x0000000: b201 7b59 c700 0757 b801 8503 324c 2ab7 0x0000010: 0001 2a01 b500 022a 03b5 0003 2a01 b500 0x0000020: 042a 01b5 0005 2a01 b500 062a b300 072b 0x0000030: 0304 54b1 @ java.lang.class.forname0(native method) @ java.lang.class.forname(class.java:264) @ com.lucent.oms.infra.subsysctrl.genericsubsysctrlhandler.<init>(genericsubsysctrlhandler.java:50) @ com.lucent.oms.infra.subsysctrl.subsysctrlhandler.<init>(subsysctrlhandler.java:36) @ com.lucent.oms.infra.subsysctrl.simplesubsystem.initsubsysctrlhandler(simplesubsystem.java:300) @ com.lucent.oms.infra.subsysctrl.simplesubsystem.<init>(simplesubsystem.java:228) @ com.lucent.oms.infra.subsysctrl.simplesubsystem.main(simplesubsystem.java:1442)
the verifyerror includes offending byte code hex dump. when decode it, get:
0 getstatic [379] 3 dup 4 ifnonnull @7 7 pop 8 invokestatic [389] 11 iconst_0 12 aaload 13 astore_1 14 aload_0 15 invokespecial [1] 18 aload_0 19 aconst_null 20 putfield [2] 23 aload_0 24 iconst_0 25 putfield [3] 28 aload_0 29 aconst_null 30 putfield [4] 33 aload_0 34 aconst_null 35 putfield [5] 38 aload_0 39 aconst_null 40 putfield [6] 43 aload_0 44 putstatic [7] 47 aload_1 48 iconst_0 49 iconst_1 50 bastore 51 return which differs original code have posted, in recognizable pattern. inserted empty lines make easier recognize original code within new code. it’s obvious code has been instrumented tool adding action on method entry , method exit.
the problem original code branch-free whereas new code contains conditional branch position 4 position 11 (4+7). should recognize these parts in verifyerror’s message: “expecting stackmap frame @ branch target 11” , “@4: ifnonnull”. error doesn’t lie in original code in code injected byte code instrumentation tool.
starting class files v51 (java 7), stackmaps became mandatory while v50 (java 6) verifier switches on old legacy verifier if error these stackmaps occurs. intended provide time updating tools, cannot deal stackmaps, instead caused more unawareness regarding inability.
so practical consequences? have identify tool performed invalid instrumentation , update (hoping update exist). might include frameworks responsible resource injection, aop or profiling. usually, these tools settle on lower level byte code engineering library, , might sufficient update library only. well, if identified responsible library may search “library name + java8 problems” find more specific solutions.
Comments
Post a Comment