java.lang.VerifyError in bespoke shared kotlin lib

Support
1

Please bear with me…this is a difficult error for which to lay the context.

java : 1.8 u191 (openjdk)
kotlin: 1.3.21
build: gradle 4

Summary: I have a shared library written in kotlin, that I reference as a compile time dependency in gradle. Within this lib, I have the following top level functions declared:

fun executeRule(ruleContextMap: MutableMap<String, Any?> = mutableMapOf(), rule: Rule): Boolean { ... }

inline fun <reified T> executeRuleWithSideEffect(ruleContextMap: MutableMap<String, Any?> = mutableMapOf(),
                                             rule: Rule, contextKey: String)
    : Pair<Boolean, T?> { ... }

the key point to note here is that the first parameter has a default applied in both methods.

Now the call site (fortunately also kotlin, but in a separate application):

executeRule(ruleContextMap = mutableMapOf(), rule = systemEventInterestRule)

This currently throws a peculiar error when run with gradle:

    java.lang.VerifyError: Bad local variable type
    Exception Details:
      Location:
        com/company/rule/dsl/Rule_supportKt.executeRuleWithSideEffect$default(Ljava/util/Map;Lcom/company/rule/dsl/Rule;Ljava/lang/String;ILjava/lang/Object;)Lkotlin/Pair; @136: aload
      Reason:
        Type long_2nd (current frame, locals[5]) is not assignable to reference type
      Current Frame:
        bci: @136
        flags: { }
        locals: { 'java/util/Map', 'com/company/rule/dsl/Rule', 'java/lang/String', integer, long, long_2nd, top, integer, 'kotlin/Pair', long, long_2nd, 'java/lang/Boolean' }
        stack: { }
      Bytecode:
        0x0000000: b801 a93a 051d 047e 9a00 0c19 0510 7304
        0x0000010: 54a7 001a 1905 1074 0454 bb01 0d59 b701
        0x0000020: 0ec0 0043 4b19 0510 7504 5403 3e00 1905
        0x0000030: 1076 0454 b800 cb37 0903 360b 1905 1077
        0x0000040: 0454 2b2a b900 3b02 00b8 00cf 3a0b 1905
        0x0000050: 1078 0454 bb00 d159 b800 cb16 0965 b800
        0x0000060: d619 0bb7 00d9 3a08 1908 b600 dc19 0510
        0x0000070: 7904 54c0 00de b600 e137 0419 08b6 00e4
        0x0000080: c000 aab6 00ad 3607 1905 107a 0454 b800
        0x0000090: e612 e815 07b8 00cf 1604 b800 d6b9 00ec
        0x00000a0: 0400 1905 107b 0454 b800 e6b9 00ef 0100
        0x00000b0: 9a00 0c19 0510 7c04 54a7 003b 1905 107d
        0x00000c0: 0454 b800 e612 f12a 1276 b900 f502 0059
        0x00000d0: c700 13bb 00f7 5912 f9b7 00fa 1905 107e
        0x00000e0: 0454 bfc0 0067 b800 feb9 0102 0300 1905
        0x00000f0: 107f 0454 2a2c b900 f502 0005 1301 15b8
        0x0000100: 0119 c000 043a 0819 0511 0080 0454 bb00
        0x0000110: d159 1507 b800 cf19 08b7 00d9 1905 1100
        0x0000120: 8104 54b0                              
      Stackmap Table:
        append_frame(@20,Object[#427])
        same_frame(@43)
        full_frame(@188,{Object[#67],Object[#55],Object[#143],Integer,Long,Integer,Object[#209],Long,Object[#170]},{})
        full_frame(@227,{Object[#67],Object[#55],Object[#143],Integer,Long,Integer,Object[#209],Long,Object[#170]},{Object[#25],Object[#143],Object[#4]})
        same_frame(@244)

There are two points that puzzle here. Firstly, the stack seems to be complaining about the inline function that I’m not calling. Secondly, if I modify both functions and remove the defaults from that first parameter, everything works.

Finally, of course, this doesn’t happen in the IDE…it only crashes on the command line. Any help appreciated.

2

Hi. This is somewhat similar to https://youtrack.jetbrains.com/issue/KT-29582, although I could only reproduce that issue with Jacoco plugin enabled. Do you have it enabled in your project as well?

Anyway, please report this issue at http://kotl.in/issue with a sample project to reproduce. Thanks!

3

Well, as could have been predicted, I cannot reproduce the issue now. However, it is not quite like for like…since that time I’ve also made other subtle changes to the class hierarchy in the DSL, so the problem may have vanished for other reasons.
I suppose I would consider this a noop, as I’m not too keen on undoing all changes. Thank you for looking into this, at any rate.

1 Like