We have one request what execute by Alamofire on swift side, but called from kotlin side from suspended function. At some moment we got crash:
* thread #34, queue = 'NSOperationQueue 0x2806ce400 (QOS: UTILITY)', stop reason = EXC_BAD_ACCESS (code=1, address=0x38)
frame #0: 0x000000010216fbf8 MultiPlatformLibrary`UpdateHeapRef + 204
frame #1: 0x0000000101eb006c MultiPlatformLibrary`blockDisposeHelper + 16
frame #2: 0x000000021eb14a44 libsystem_blocks.dylib`_Block_release + 152
frame #3: 0x0000000102d54f34 MultiPlatformLibraryMaps`___lldb_unnamed_symbol3$$MultiPlatformLibraryMaps + 24
frame #4: 0x000000010413d9fc libswiftCore.dylib`_swift_release_dealloc + 28
frame #5: 0x0000000102d53fec MultiPlatformLibraryMaps`___lldb_unnamed_symbol2$$MultiPlatformLibraryMaps + 36
frame #6: 0x000000010413d9fc libswiftCore.dylib`_swift_release_dealloc + 28
frame #7: 0x00000001018a0dc8 Alamofire`___lldb_unnamed_symbol42$$Alamofire + 56
frame #8: 0x000000010413d9fc libswiftCore.dylib`_swift_release_dealloc + 28
frame #9: 0x00000001018a0ea4 Alamofire`block_destroy_helper.5 at <compiler-generated>:0
frame #10: 0x000000021eb14a44 libsystem_blocks.dylib`_Block_release + 152
frame #11: 0x000000021fa14360 Foundation`-[NSBlockOperation dealloc] + 64
frame #12: 0x000000021eb14a44 libsystem_blocks.dylib`_Block_release + 152
frame #13: 0x00000001049d11d0 libdispatch.dylib`__destroy_helper_block_ + 112
frame #14: 0x000000021eb14a44 libsystem_blocks.dylib`_Block_release + 152
frame #15: 0x00000001049d0de4 libdispatch.dylib`_dispatch_client_callout + 16
frame #16: 0x00000001049d41e0 libdispatch.dylib`_dispatch_continuation_pop + 528
frame #17: 0x00000001049d3620 libdispatch.dylib`_dispatch_async_redirect_invoke + 632
frame #18: 0x00000001049e21f8 libdispatch.dylib`_dispatch_root_queue_drain + 376
frame #19: 0x00000001049e2be4 libdispatch.dylib`_dispatch_worker_thread2 + 156
frame #20: 0x000000021ec9a190 libsystem_pthread.dylib`_pthread_wqthread + 472
* frame #21: 0x000000021ec9cd00 libsystem_pthread.dylib`start_wqthread + 4
it reproduce on devices more times, then simulators.
sample app here - https://github.com/Alex009/kotlin-native-updateheapref-crash/tree/master
Thank you for the report, we have successfully reproduced the crash on our side.
This is known issue (e.g. reported in https://github.com/JetBrains/kotlin-native/issues/2052#issuecomment-497744950). I'm afraid no workaround available.
If the issue is the fact that the lambda is release too early then the workaround I found is to save the lambda in a member variable of the class that calls it. It is not very pretty in the code vut in my case it prevented the crash.
If the issue is the fact that the lambda is release too early
No.
Ok fait enough. That is not the issue.
But my stack trace looks similar to this one so I hope my fix can help Alex009.
You likely encounter the same issue, and this workaround can help because the crash is caused by the fact that Swift lambda gets deallocated by wrong thread thus accessing Kotlin lambda from wrong thread.
So saving it to a variable may help if the variable doesn't get nullified/overwritten until the background job has finished. The problem is to
Fix will be shipped with Kotlin 1.3.60.
Most helpful comment
Fix will be shipped with Kotlin 1.3.60.