Kotlinx Coroutines upgrade to 1.3.7 causes VerifyError

[nheitz]

Hello. Not entirely sure how to generate a good small sample project to reproduce this, so I will start by simply stating the symptoms and the apparent trigger.

OS: Ubuntu 20.04
Platform: JVM (JDK 8)
Kotlin: 1.3.72
Coroutines; 1.3.7

Code base compiles, but when running a component test:

java.lang.VerifyError: Bad type on operand stack
Exception Details:
  Location:
    xxx/catapult/server/services/DefaultCatapultService.submit(Lxxx/catapult/api/request/CatapultRequest;Lkotlin/Pair;)Lkotlin/Pair; @248: invokespecial
  Reason:
    Type 'java/lang/Exception' (current frame, stack[6]) is not assignable to 'kotlin/jvm/internal/Ref$ObjectRef'
  Current Frame:
    bci: @248
    flags: { }
    locals: { 'xxx/catapult/server/services/DefaultCatapultService', 'xxx/catapult/api/request/CatapultRequest', 'kotlin/Pair', 'xxx/catapult/api/job/JobId', 'java/lang/String', 'xxx/catapult/api/job/AsyncJob', 'xxx/catapult/api/utils/coroutines/RequestExecutionContext', top, 'java/lang/Exception', integer, 'xxx/catapult/api/job/AsyncJob' }
    stack: { 'xxx/catapult/api/job/AsyncJob', null, uninitialized 237, uninitialized 237, 'xxx/catapult/server/services/DefaultCatapultService', 'xxx/catapult/api/job/AsyncJob', 'java/lang/Exception', 'kotlin/Pair', null }
  Bytecode:
    0x0000000: 2b12 1ab8 0020 2ab4 0024 b600 2a9a 002c
    0x0000010: b200 2eb8 0034 1236 2ab4 003a b600 40b8
    0x0000020: 0046 b900 4c03 00bb 004e 592a b400 3ab6
    0x0000030: 0040 b700 52c0 0054 bf2a 2b2c 59c6 000c
    0x0000040: b600 afc0 00b1 a700 0557 01b7 00b5 4e2b
    0x0000050: b600 bb3a 0503 3606 0336 0719 053a 0803
    0x0000060: 3609 1908 b200 c1b6 00c4 b900 ca02 0059
    0x0000070: c600 06a7 0011 5719 08b2 00cd b600 c4b9
    0x0000080: 00ca 0200 59c1 00b1 9a00 0557 01c0 00b1
    0x0000090: 3a04 2ab4 00d0 2dbb 00d2 592d 2b19 04b7
    0x00000a0: 00d5 c000 d7b9 00db 0300 5912 ddb8 0065
    0x00000b0: c000 943a 05b8 00e3 3a06 1905 b600 e619
    0x00000c0: 053a 0a00 190a 2a19 06bb 00e8 592a 2b19
    0x00000d0: 052c 01b7 00eb c000 edb7 00f1 3a07 a700
    0x00000e0: 293a 0819 0a2a b400 24b6 0078 01bb 00f3
    0x00000f0: 592a 1905 1908 2c01 b700 f6c0 009b 0401
    0x0000100: b800 a1c0 0054 bf19 07b6 00fa 2d19 05b8
    0x0000110: 0100 b0                                
  Exception Handler Table:
    bci [195, 222] => handler: 225
  Stackmap Table:
    same_frame(@57)
    full_frame(@73,{Object[#2],Object[#183],Object[#110]},{Object[#2],Object[#183],Object[#110]})
    full_frame(@75,{Object[#2],Object[#183],Object[#110]},{Object[#2],Object[#183],Object[#177]})
    full_frame(@118,{Object[#2],Object[#183],Object[#110],Object[#86],Top,Object[#198],Integer,Integer,Object[#198],Integer},{Object[#4]})
    same_locals_1_stack_item_frame(@132,Object[#4])
    same_locals_1_stack_item_frame(@141,Object[#4])
    full_frame(@225,{Object[#2],Object[#183],Object[#110],Object[#86],Object[#177],Object[#148],Object[#272],Top,Object[#198],Integer,Object[#148]},{Object[#172]})
    full_frame(@263,{Object[#2],Object[#183],Object[#110],Object[#86],Object[#177],Object[#148],Object[#272],Object[#274],Object[#198],Integer,Object[#148]},{Object[#148]})


	at xxx.catapult.server.services.CatapultServiceTest.setUp(CatapultServiceTest.kt:127)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
	at com.github.tomakehurst.wiremock.junit.WireMockRule$1.evaluate(WireMockRule.java:73)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
	at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
	at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
	at com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
	at com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230)
	at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)

If I simply revert to coroutines 1.3.6 and recompile, issue disappears. Nothing in the 1.3.7 release notes suggests to me where the problem might reside.

[qwwdfsad]

It seems to be a duplicate of #2041.

Copying my response here:

Unfortunately, this is a bug in Kotlin compiler related to function with contracts that were added in #2030.
We are working on the fix, a workaround is to extract withContext calls from try and catch blocks (I'll try to post more specific workaround later) to separate functions.
Sorry for the inconvenience!

Please see if that helps. Apart from withContext, it can be any coroutine builder marked with experimental contract: runBlocking, coroutineScope etc.

[nheitz]

Thank you for your response. There does appear to be correlation with the use of a try-catch block around a coroutine method. In my case, however, I've narrowed it down yet further to one line of code.

        } catch (e: Exception) {
            catapultExecutionSemaphore.release()

            throw runBlocking { handleThrowable(asyncJob.jobId, e, extRefChannelPair) }
//            throw e
        }

If I run this, I get the failure (handleThrowable posts the error to a return channel, then returns the unwrapped exception).

If, however, I simply "throw e", rather than process it in runBlocking, the code completes execution successfully.
If that still strikes you as the same cause, then i will close this Issure, but I want to be sure.

[qwwdfsad]

Yes, that's the same problem, thanks for double-checking.
As a workaround, you can extract runBlocking to a separate function like this:

 } catch (e: Exception) {
catapultExecutionSemaphore.release()
   throw handleThrowableBlocking(...)
}